[cryptography] Just how bad is OpenSSL ?
matthewdgreen at gmail.com
Tue Oct 30 10:21:00 EDT 2012
1. What is the process by which you get OpenSSL contributors to notice a serious issue and apply a patch?
2. What are the criteria for applying a patch? Is it just 'whatever interests the devs'? It seems that publishing an exploit works, but is that necessary?
3. It's 2012 -- why the **** is OpenSSL running its own ticket tracker and source control servers??? (RT is a disaster.)
4. What does it take to become an OpenSSL volunteer?
On Oct 30, 2012, at 10:12 AM, Ben Laurie <ben at links.org> wrote:
> On Tue, Oct 30, 2012 at 11:58 AM, Jeffrey Walton <noloader at gmail.com> wrote:
>> On Tue, Oct 30, 2012 at 5:03 AM, Ben Laurie <ben at links.org> wrote:
>>> On Mon, Oct 29, 2012 at 10:34 PM, Jeffrey Walton <noloader at gmail.com> wrote:
>>>> On Fri, Oct 26, 2012 at 2:29 PM, John Case <case at sdf.org> wrote:
>>> Apparently you think the best way to get a secure platform is to apply
>>> pressure through pointless security standards. I'd suggest your
>>> efforts might be better spent supplying patches instead. Or, y'know,
>>> talking to the authors of the s/w in question. You never know, they
>>> might care.
>> Ah, OK. My bad.
>> I've tried supplying patches and filing bug report/enhancement requests.
>> Here was a gentle patch for spelling corrections in a README -
>> rejected. http://rt.openssl.org/Ticket/Display.html?user=guest&pass=guest&id=2401.
> AFAICS that is not rejected, it is ignored. There's a difference.
> Also, your patch appears to be reversed. Or your spelling is terrible :-)
>> Here was a patch for Xcode awareness - rejected (is it fair to say
>> when its sites for years without acknowledgement?).
> Also not rejected.
> Now, I agree that having patches ignored isn't so great either, but
> the problem is:
> * RT doesn't actually work, the guy who allegedly maintains our
> infrastructure doesn't, and the team can't agree what to do about it
> (not that its tried very hard).
> * OpenSSL is mostly maintained by volunteers, who may not have felt
> particularly inspired by your patches, or may just have missed them.
> * When people are paid, they're generally paid to do specific things,
> not to trawl through RT (if they even could) looking for patches to
> adopt. I'm sure someone could pay for that if they want to, though.
> * CVS is a shit tool, too, making it hard to deal with patches - we've
> even agreed as a team to move off it, but see above about
> infrastructure :-)
>> I can't locate a bug report on the use of the uninitialized data.
>> Perhaps I had the discussion on the developer's mailing list (I know
>> I'm not imagining it, so my apologies).
>> I am also aware that patches existed for some time for CCM mode, GCM
>> mode, and SRP. In the case of GCM, IBM supplied the patches 5 or 10
>> years earlier. None were acted upon.
> It always amuses me when bigcorp pays to have a patch made, but
> somehow manages to fail to understand that the guy applying the patch
> has to eat, too. Plus, ISTR the IP situation is none too clear on all
> of these.
> This reminds me of the first attempt to FIPSify OpenSSL, where there
> was zero budget for the developer - just money for test labs and the
> like ("what do you mean you want money to work on it? I thought it was
> free software!").
>> The project does not appear to want outside help. If I am drawing the
>> wrong conclusion, please forgive me.
> I'll grant you that your very small patches could be considered help,
> and it is a little unfortunate they they were ignored, but like I say,
> RT is a shit tool, at least as implemented at OpenSSL, as is CVS (I
> notice you didn't supply the needed 4 patches, just a single one) and
> no-one's paying anyone to pick patches up from it, particularly.
> The rest of your "help" appears to be specifying flags you'd like to
> be used and expecting us to do the work for you. Which I actually
> might, I find that kind of thing therapeutic, but you get my point.
> I think the project would welcome help - but it needs to be useful help :-)
> cryptography mailing list
> cryptography at randombit.net
More information about the cryptography