On 2013-12-18 17:35, Daniel Stenberg wrote:
> On Wed, 18 Dec 2013, Leif W wrote:
>
> Thanks Leif for doing this and "taking one" for the team.

No problem. Thanks for this crazy cURL program development for many years.

> It clearly primarily describes how you get the Mozilla source code
> over plain HTTP. That's not secure by any means.

With respect to Mozilla, whom I know has lots of hands on code and
eyeballs looking into all manner of technical things and making cool
software, but the website documentation is sometimes awful.
Disorganized, outdated, inconsistent. It may be a case of that here.
Later in the same doc, they specify using https. Maybe someone made a
typo at the first http. ;) If I knew more, I'd offer to do something
about it. Not sure I am up for that learning curve, though.

> 6) Not manually reviewing all of a certdata.txt AND the release notes,
>> (BEFORE using it for anything).
>
> I think someone is misunderstanding what the purpose of the script is.

I think the mindset was, if you don't know what is changing or why, or
not doing something in a complete pristine way, you may as well not be
using https at all because your trust is worthless. Oh boy, I
understand this concern, I think. And also understand the mk-ca-bundle
script is just a quick and dirty way to make something work, when
security may not be of much concern.

>> 7) Not bundling certdata.txt in cURL to avoid
>> chicken/egg/trust/review issues.
>
> I think someone is misunderstanding what the purpose of the script is.
> I have no intention bundle this with any release of curl for several
> reasons which I don't think I'll go into right now.

I think they put a lot of hard work into ensuring the CA's listed are
100% trustworthy, and are accustomed to ensuring that any security
module that relies on that trust, handles the data (transmissions, etc)
in such a way that maintains that trust. Rightly so, for the world's
leading browser technology over 20 years old now. They must develop
Policy and Procedures which maintain the trust, as well as Code things.
cURL's usage scope is .. different. :)

>> 8) Using certdata.txt outside of Mozilla projects,
>> (as file format may change at any time without notice).
>
> That's just silly. If the script breaks it breaks. Then someone either
> fixes the script or won't get a suitable output. That script and its
> anscestors have worked fine enough for over 5 years by now.

I think similar to the more recent change how the file format changed,
was still processed successfully, but was trusting everything instead of
distrusting some.

There was one other thing, with stricter processing inside other code in
NSS or Gecko, which could not at present be quantified, extracted,
duplicated or bundled separately. Maybe they do more analysis on each
site certificate at run time, etc. Not sure of the details, but I
understand the concern. Out of our scope for now.

>> 11) In general, not being responsible or security conscious.
>
> I get that attitude much too often from "security experts" all over
> when I do things in curl. Or for not doing enough things.

As they are working with it every day at a very deep level of
understanding, and see many more cases of what can go wrong and how
badly when things are not handled strictly, I can understand the
sensitivity, and given their tasks with a hugely popular browser,
completely justified. I am mindful of that. I am just honored to get a
glimpse into their experience.

> The challenge is to extract the facts and the "good" points and work
> on improving those things.

Hmm, mostly good points. But points within scope, and within my skill
level to do something about. If I leave the script in a better state
than I found it, and leave behind a record of additional concerns, I
consider my goal complete.

>> me just becoming a Mozilla employee probably makes me an even better
>> candidate for that position! ;-)

Congratulations!

> Possibly you now have some feedback to update it slightly,

Wondering about an idea: If we know what certificate is used for https
on a release repository, and we know what certificate authority will be
used to check that cert, maybe we could include just that CA in the
mk-ca-bundle (in a HERE document assignment to a variable). Maybe still
too much maintenance, but trying to think of a hybrid idea. That could
satisfy as much as possible while minimizing administrative burden of
maintainability.

Other than that, not sure how to improve output. The -t and -v options
provide extra info for review of what mk-ca-bundle is doing.

> and possibly we should also make it output some general warnings in
> the spirit you

"Warning: Use of this script will make a security engineer grind his
teeth and swear at you." ;)

Maybe always print out:

"Use of this script may pose some risk, -d risk for more details." And
then describe more there?

>> The db2pem shell script is handy, if you're a Firefox user on a *nix
>> system. That maybe could be adapted to a more portable language (Perl
>> and/or PHP?).
>
> Yes, that would be neat. I would guess that it could then also be made
> to work on Windows etc with some adaptions...

Yes, I think I could make one script of each language run portably from
a single source and single language. Or a .vbs. If I was really
clever, I'd put the core logic in a template, and generate the scripts
using a stub / wrapper script in specific language. Centralize the
common code, minimize the disparate platform code. Ah but I may not be
that clever yet. ;(

Leif

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-users
FAQ: http://curl.haxx.se/docs/faq.html
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2013-12-19