Tested ebuild in attachment Reproducible: Always
Created attachment 416452 [details] aircrack-ng-1.2_rc1-r2.ebuild
Created attachment 416454 [details] aircrack-ng-1.2_rc2-r1.ebuild
Created attachment 416456 [details] aircrack-ng-9999-r1.ebuild
Created attachment 416566 [details, diff] aircrack-ng-1.2_rc1-r2.ebuild.patch
Created attachment 416568 [details, diff] aircrack-ng-1.2_rc2-r1.ebuild.patch
Created attachment 416570 [details, diff] aircrack-ng-9999-r1.ebuild.patch
you have added a patch, which is great, but you skipped why I should care. please start with that. this is a password cracker, does this make it faster? slower? what?
There is not a stable support for libressl in gentoo yet. These patches are meant to add that support, one package at a time. OpenSSL and LibreSSL cannot be installed at the same time, so with a stable libressl support when user chooses libressl, he will not be able to install aircrack-ng (because it depends on openssl). Unless these patches are accepted.
(In reply to Marek Behun from comment #8) > There is not a stable support for libressl in gentoo yet. These patches are > meant to add that support, one package at a time. OpenSSL and LibreSSL > cannot be installed at the same time, so with a stable libressl support when > user chooses libressl, he will not be able to install aircrack-ng (because > it depends on openssl). Unless these patches are accepted. if openssl and libressl are equivilent then make a virtual. if they aren't, then baring extensive testing I fail to see why I should care if aircrack-ng allows libressl or not.
See here the discussion why it was decided to go with libressl useflag instead of virtuals. http://thread.gmane.org/gmane.linux.gentoo.devel/91899/focus=94484 I don't see why it is a problem to add this to the ebuild. The libressl use flag is masked from stable anyway, it is not like ordinary users are going to build aircrack-ng against libressl. The package compiles without warnings agais SSL library. Other packages are doing this, see bug 565372, bug 565252, bug 565244, bug 565274 and othes (search for libressl).
(In reply to Marek Behun from comment #10) > See here the discussion why it was decided to go with libressl useflag > instead of virtuals. > http://thread.gmane.org/gmane.linux.gentoo.devel/91899/focus=94484 > > I don't see why it is a problem to add this to the ebuild. The libressl use > flag is masked from stable anyway, it is not like ordinary users are going Just a general observation/comment: Any addition of use flag increase complexity and potentially maintainer burden over time. In particular when the use flag adds dependencies on potentially competing namespaces that are not ABI nor API compatible. Upstream might think they are doing people a service by not having to rewrite things, but the long term result is just utter craziness. So as a hypothetical question (as I'm not maintaining the question in the first place, but just curious based on the thread); if adding this use flag, would you be prepared to provide fixes related to it in the long term, not only a single patch-and-run? Also keeping in mind that a crypto provider is a security sensitive core component..
> Just a general observation/comment: Any addition of use flag increase > complexity and potentially maintainer burden over time. In particular when > the use flag adds dependencies on potentially competing namespaces that are > not ABI nor API compatible. Upstream might think they are doing people a > service by not having to rewrite things, but the long term result is just > utter craziness. There is no disagreement with me here, but I thought that Gentoo does want to support LibreSSL... > So as a hypothetical question (as I'm not maintaining the question in the > first place, but just curious based on the thread); if adding this use flag, > would you be prepared to provide fixes related to it in the long term, not > only a single patch-and-run? Also keeping in mind that a crypto provider is > a security sensitive core component.. To answer that question I looked into the sources of aircrack-ng and discovered that the only usage of OpenSSL is for SHA and HMAC hashing, and AES and RC4 ciphers. Those are also supported by LibreSSL's crypto library and if they were slow or buggy, someone would already notice, because LibreSSL is already widely used (Max OS X for example switched from OpenSSL to LibreSSL already). Nothing else is used from libcrypto or libssl, so I am confident enough that even if it would be a problem in the future, it would be solvable pretty quickly.
