Since there are a couple large features that are in the queue, I am deciding to stop features on current branch (1.x) and starting a new branch (2.x) for the new features:
* #573728: Utilize ctools plugins for key methods
* #609592: Support for PHP Secure Communications Library (phpseclib)
This means I will be releasing a 1.0 in a few moments.
Comments
Comment #1
giorgio79 commentedDo you have a timeframe on the 2x release?
Comment #2
zzolo commentedI haven't had much time to put towards this module in a while. I also don't have any timeline for this. I open to patches and possibly co-maintainers.
Comment #3
ClearXS commentedMaybe have a look at the several other encryption modules (sometimes not maintained for some time) and ask their maintainers to join; maybe together there is synergy and more 'horsepower'?
Think there should be one Encryption API module that does all the possible encryptions.
Same for a 'login security API' that has to do all types of login securities , but it should use encryption methods of the Encryption API as a dependency.
Then the USB keys authentications work with USB's that have to be bought, instead of that one puts its own key on its own USB-stick
http://drupal.org/project/yubikey - http://drupal.org/project/swekey
Comment #4
gregglesIn my opinion it no longer makes sense to have a 6.x-2.x branch of this module. If people want that code they can upgrade to 7.x-2.x.
I think that the 7.x-2.x branch is very close to being ready for a final 7.x-2.0 release. If anyone else has ideas on what to improve before then please post a comment here or an issue.
Comment #5
gregglesI removed the AES combination idea and subbed in a new bug that needs some review. I haven't looked into it yet, but we should confirm that's not an issue in 7.x-2.x.
Comment #5.0
gregglesx
Comment #6
rickmanelius commentedHi Everyone. I had a fairly interesting conversation with a company (Townsend Security) that is looking to help create a 2.0 release. Looking at the issue summary, it appears that there is only one remaining feature request for the 7.x-2.0 release. Is that still accurate? If not, it would be helpful to get an updated punchlist so we can get a better understanding of the amount of effort it would take to achieve that goal.
Comment #7
gregglesThere's a list of bugs, features and tasks for 7.x and I think there's about a dozen or so that should ideally get fixed before a stable release. None or supremely complex, but all should have automated tests.
I'll be around on Friday for anyone interested to work on this. Happy to strategize and agree on a plan and path to release.
Comment #8
rlhawkMy understanding is that #1927572 does not apply to 2.x, so it shouldn't block a release, and I think everything else has been addressed. There are two issues that aren't blocking, but if we can get them RTBC soon, I'd love to get them committed.
There have been some significant changes since 7.x-2.x-beta3, so I propose an RC1 (or beta4) and make it the recommended version. If all is well after a few weeks, we can release 2.0. Then, it's Drupal 8 time.
Comment #9
gregglesThe plan in #8 makes sense to me. Let's make it an RC1 to make it clear that the next thing is a full release.
Thanks, rlhawk!
Comment #10
rlhawkTerrific. I've tagged and created the release and made it the recommend one.
Comment #11
gregglesI just reviewed the list of open issues that affect 7.x-2.x and it seems like most are not release blockers.
Let's wait another week or so and try to get some more testing and go from there.
Comment #12
rlhawkThat sounds good to me.
Comment #13
rlhawkI tried the latest version of Encrypt with the recommended release of the Webform Encrypt module (1.0) and it failed with a fatal error when trying to encrypt. It did the same thing with 2.0-beta3, so any problem was not introduced in rc1. I tried again with Encrypt 1.1 and it worked better, encrypting and decrypting as desired, but a lot of warnings and notices were thrown, but only on the main Results page. I got the same success-with-warnings-and-notices result using Encrypt 2.0-rc1 and the latest dev version of Webform Encrypt. All indications are that any issues are with Webform Encrypt, especially since it seems to be not actively maintained at this point.
Comment #14
rlhawkComments in issue #254979 seem to support my conclusion.
Comment #15
rlhawkI installed Alan D's sandbox project, Webform Encrypted Components, which worked perfectly with Encrypt 1.1, but threw a fatal error with any 2.x versions, because the module doesn't just use encrypt() and decrypt(). It calls encrypt_initialize(), which was removed in Encrypt 2.x.
Comment #16
gregglesOK, I filed #2325353: Compatability with Encrypt 7.x-2.x for webform encrypt. I think we should just file issues and add them to a listing.
Do you have a list of modules that use Encrypt? That seems like a nice thing to have on the project page and then we could show a table of which versions of the modules are generally working, work with 7.x-1.x, work with 7.x-2.x.
Comment #17
cellar door commentedWould it be helpful if we arranged a hangout for maintainers and contributors for the various encryption modules (field and webform are first that come to mind) to discuss roadmap and syncing up with 2.x? We can then come away with stronger docs for both implementing developers as well as contributors since a lot has changed in 2.x
Comment #18
gregglesI'm open to being on a hangout and editing docs, though probably couldn't organize one or write the docs you mention.
Comment #19
rlhawkI've updated the project page, in preparation for releasing version 2.0.
Comment #20
gregglesGreat, thanks! I think it's probably time :)
Removing #1927572: Key file is never used from the issue summary because it's about 7.x-1.x.
Comment #21
rlhawkDone!