claudijd/c7decrypt

Cisco Password Encryptor/Decryptor

c7decrypt's Issues

Move Custom Exception classes into their own namespace

Current Namespaces:

C7Decrypt::Type7::InvalidFirstCharacter
C7Decrypt::Type7::InvalidCharacter
C7Decrypt::Type7::OddNumberOfCharacters
C7Decrypt::Type7::InvalidEncryptionSeed

Proposed Namespaces:

C7Decrypt::Type7::Exceptions::InvalidFirstCharacter
C7Decrypt::Type7::Exceptions::InvalidCharacter
C7Decrypt::Type7::Exceptions::OddNumberOfCharacters
C7Decrypt::Type7::Exceptions::InvalidEncryptionSeed

In order to do this, I believe it's also a good convention to blow the types into their own folders and then have the proper type#.rb and associated exceptions.rb for each.

Drop redundant spec class validation in specs

Example:

@c7d = C7Decrypt.new()
....
subject{@c7d}
its(:class) {should == C7Decrypt}

Your gem is empty?

  c7decrypt-0.2.0:
  total used in directory 0 available 86825190
  drwxrwxr-x+  3 ryan  staff   102 May 25 19:29 .
  drwxrwxr-x+ 37 ryan  staff  1394 May 25 19:29 ..
  drwxrwxr-x+  2 ryan  staff   102 May 25 19:29 lib

 c7decrypt-0.2.0/lib:
  total used in directory 8 available 86825190
  drwxrwxr-x+ 2 ryan  staff  102 May 25 19:29 .
  drwxrwxr-x+ 3 ryan  staff  102 May 25 19:29 ..
  -rw-r--r--+ 1 ryan  staff   58 May 25 19:29 c7decrypt.rb

???

Create Automatic Git Tagging for Each Release in Rake-base Release Process

Using the rake-based release process for releasing a new rubygem, it should automatically tag the release so I'm properly populating tag information on every gem release.

Support Alternate Type Formats

Reference: https://twitter.com/michaelmcatee/status/533764636617617408

Add Better Exception Handling to the C7Decrypt "decrypt" Function

C7Decrypt is now being used in a service (ThreatAgent) and probably getting some decent usage via user input. As such, I'd like to be a bit smarter about what happens if we're provided invalid or malformed hashes from an end-user.

Here are some conditions that I'm thinking about handling better:

1.) User presents a hash to the decrypt function which contains a non-numeric first character
2.) User presents a hash to the decrypt function which contains lower-case alpha chars
3.) User presents a hash to the decrypt function which contains something other than alpha-numeric characters.

I think that these three cases would throw the following Ruby exceptions respectively:

1.) InvalidFirstCharacter
2.) InvalidLowerCaseLetter
3.) InvalidCharacter

Note: The implementer of the decrypt function would then need to be informed of these custom exceptions (likely via Yard documentation) and would need to implement exception handling if the string being supplied is "unknown" or "user controlled"

Some other thoughts would be to talk to Marcus and get feedback on whether this is something (1) that is reasonable for his current use case and (2) whether it would reasonable to get telemetry data on these exceptions and any other standard exceptions that are thrown by the library to help bolster it's exception handling.

Move Exceptions code inside c7decrypt.rb to avoid require_relative and bring back support for legacy rubies.

Restore RBX Builds when Travis' RBX builds are fixed

Upstream Issue Reference:

travis-ci/travis-ci#1641

Related Work Around Commits to get Travis builds to pass:

bfcc162

Implement Fuzzing Rake Tasks to Make C7Decrypt more Awesome

I heard about this interesting gem called fuzzbert, which does random fuzzing against ruby-based apps. I think it would be cool if C7Decrypt implemented two rake tasks to make it easier to fuzz the app and find bugs in the library.

1.) Implement a rake task for light fuzzing routine that can regularly test the library during it's regular CI runs. Maybe this could be limited, but random so we'll periodically cover more testing space on each run.
2.) Implement a rake task for increasing levels of thoroughness (perhaps parameterized for time or test coverage) to afford myself and other users of the library to discover bugs in the library.

Also, looking for additional ideas here if anyone reading this is interested in this idea too.