Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

1.9 compatibility #2

Closed
mkfs opened this issue Dec 16, 2011 · 7 comments
Closed

1.9 compatibility #2

mkfs opened this issue Dec 16, 2011 · 7 comments

Comments

@mkfs
Copy link

mkfs commented Dec 16, 2011

UnixCrypt.build causes a TypeError when used under Ruby 1.9.x:

TypeError at unix_crypt.rb line: 97
String can't be coerced into Fixnum

The line in question is:
ds = digest.digest(salt * (16 + a[0]))
...where 'salt' and 'a' are both strings.

The problem here is that in Ruby 1.8.x, String#[] returns a byte value, while in Ruby 1.9.x it returns a character or substring.

The way to fix this is to use String.bytes, e.g.

  ds = digest.digest(salt * (16 + a.bytes.first))
@mkfs
Copy link
Author

mkfs commented Dec 16, 2011

Here's a crude patch. Too in-the-middle-of-debugging-something to do the whole clone/fork/fix thing. Let's home github's edit widget doesn't trash things too much. Anyways, it's a two-minute manual fix (to three locations).

--- lib-orig/unix_crypt.rb 2011-12-16 17:48:15.699145334 -0500
+++ lib/unix_crypt.rb 2011-12-16 17:45:45.129145308 -0500
@@ -20,14 +20,14 @@
b64 = "./0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz"
output = ""
byte_indexes.each do |i3, i2, i1|

  •    b1, b2, b3 = i1 && input[i1] || 0, i2 && input[i2] || 0, i3 && input[i3] || 0
    
  •    b1, b2, b3 = i1 && input[i1].ord || 0, i2 && input[i2].ord || 0, i3 && input[i3].ord || 0
     output <<
    
  •      b64[  b1 & 0b00111111]         <<
    
  •      b64[  b1 & 0b00111111].ord         <<
       b64[((b1 & 0b11000000) >> 6) |
    
  •          ((b2 & 0b00001111) << 2)]  <<
    
  •          ((b2 & 0b00001111) << 2)].ord  <<
       b64[((b2 & 0b11110000) >> 4) |
    
  •          ((b3 & 0b00000011) << 4)]  <<
    
  •      b64[ (b3 & 0b11111100) >> 2]
    
  •          ((b3 & 0b00000011) << 4)] .ord <<
    
  •      b64[ (b3 & 0b11111100) >> 2].ord
    

    end

    remainder = 3 - (length % 3)
    @@ -94,7 +94,7 @@
    dp = digest.digest(password * password.length)
    p = dp * (password.length/length) + dp[0...password.length % length]

  •  ds = digest.digest(salt * (16 + a[0]))
    
  •  ds = digest.digest(salt * (16 + a[0].ord))
    

    s = ds * (salt.length/length) + ds[0...salt.length % length]

    rounds.times do |index|

@mkfs
Copy link
Author

mkfs commented Dec 16, 2011

Yeh, as I thought, github hosed it. The fix: append .ord to the string subscript in lines 23, 25, 27, 29, 30, and 97. Works fine after that.

@mogest
Copy link
Owner

mogest commented Dec 23, 2011

Hi mkfs - it looks like you're working off old code there. Someone submitted a patch in February that should fix compatibility with 1.9. Can you confirm all is well?

@mkfs
Copy link
Author

mkfs commented Dec 23, 2011

I was using the gem hosted at rubygems.org -- it does not have the patch.

I did a clone of your github and built/installed a gem from that (btw, the gemspec needs a version bump) and it works fine in Ruby 1.9:

ruby-1.9.2-head :001 > require 'unix_crypt'
=> true
ruby-1.9.2-head :002 > UnixCrypt::SHA512.build('test', '123456')
=> "$6$123456$ifjrukhcLoFUagpORAvKGgb7j0jimL3.mtYxw1pc31NB9eYAPhLRrAkU8ChHL52xCfvmaM3Li/peXeqq9jQ9C/"

@mkfs mkfs closed this as completed Dec 23, 2011
@mkfs
Copy link
Author

mkfs commented Jan 31, 2012

Could you update the gem on rubygems.org? I need to distribute my own gems with unix-crypt as a requirement, which kills my own compatibility for 1.9.x.

https://rubygems.org/gems/unix-crypt

@mogest
Copy link
Owner

mogest commented Feb 1, 2012

Gem pushed.

@mkfs
Copy link
Author

mkfs commented Feb 2, 2012

Awesome, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants