You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Yann Ylavic <yl...@gmail.com> on 2016/01/14 09:25:16 UTC

Re: [Bug 55808] File integrity verification using MD5 and SHA1

[cross posting @docs => @dev, full thread
http://www.gossamer-threads.com/lists/apache/docs/453401]

On Thu, Jan 14, 2016 at 1:50 AM, Tom Fredrik Blenning Klaussen
<bf...@blenning.no> wrote:
>
> On 14/01/16 01:19, Yann Ylavic wrote:
>>
>> as I said earlier, the way you access the
>> tarball is not that important provided you verify its signature, or
>> its digests from the official repository only.
>
> I understand what you are saying that the proper way is to download
> the checksums from the correct source, which is self-evident. Now
> assume you're a new user, and do not have this previous knowledge.
> This user is security conscious, so the user chooses https on purpose.
> He would go into (https://httpd.apache.org), where he would find a
> link taking him to (https://httpd.apache.org/download.cgi), at this
> point, he would find the link to (http://www.apache.org/dist/httpd/),
> what I'm saying is in order to have some trust in that link, it
> _SHOULD_ be https otherwise assuming you could introduce yourself as a
> MitM, manipulating the signatures would be trivial.

OK, I thought the links to the MD5/SH1/PGP were https: but this is not the case.
I agree that the origin of these files should be trustable.

@dev: should I s/http:/https:/ for those links (only) in
^httpd/site/trunk/content/download.mdtext?
Or possibly use paths instead (i.e. /dist/httpd/...) so that it
depends on /download.cgi is accessed?
Would that be enough for the prod to be updated (via staging)?

Regards,
Yann.

Re: [Bug 55808] File integrity verification using MD5 and SHA1

Posted by Yann Ylavic <yl...@gmail.com>.
Thanks, I'll read this!

On Tue, Feb 2, 2016 at 6:58 PM, Luca Toscano <to...@gmail.com> wrote:
> Hi Yann,
>
> 2016-02-02 18:41 GMT+01:00 Yann Ylavic <yl...@gmail.com>:
>>
>>
>> How do you do the "publish" part?
>>
>
> I use the bookmarklet outlined in http://www.apache.org/dev/cms.html#usage
> (didn't know what it was until Humbedooh explained to me with extreme
> patience :)
>
> I usually go to http://httpd.staging.apache.org/ after committing, and hit
> the bookmark to access the CMS page. Then the "Publish" button will push the
> changes to http://httpd.apache.org/
>
> Luca
>
>

Re: [Bug 55808] File integrity verification using MD5 and SHA1

Posted by Luca Toscano <to...@gmail.com>.
Hi Yann,

2016-02-02 18:41 GMT+01:00 Yann Ylavic <yl...@gmail.com>:

>
> How do you do the "publish" part?
>
>
I use the bookmarklet outlined in http://www.apache.org/dev/cms.html#usage
(didn't know what it was until Humbedooh explained to me with extreme
patience :)

I usually go to http://httpd.staging.apache.org/ after committing, and hit
the bookmark to access the CMS page. Then the "Publish" button will push
the changes to http://httpd.apache.org/

Luca

Re: [Bug 55808] File integrity verification using MD5 and SHA1

Posted by Yann Ylavic <yl...@gmail.com>.
Hi Luca,

On Tue, Feb 2, 2016 at 6:27 PM, Luca Toscano <to...@gmail.com> wrote:
>
> sorry for the lack of response but I didn't notice the patch.

No problem.

> I checked the
> links in staging and published the patch to
> https://httpd.apache.org/download.cgi (hope that it is ok for you).

How do you do the "publish" part?

Regards,
Yann.

Re: [Bug 55808] File integrity verification using MD5 and SHA1

Posted by Luca Toscano <to...@gmail.com>.
2016-02-02 21:10 GMT+01:00 Tom Fredrik Blenning Klaussen <bf...@blenning.no>:

>
> Having reviewed the changes I think they're good, but not complete.
> The remaining http links should be changed to // .
> Eg "http://httpd.apache.org/mod_ftp/" should be changed to
> "//httpd.apache.org/mod_ftp/" for all links containing apache servers.
> I'm not sure if external links needs to be changed, but to the extent
> they work I see nothing wrong in changing them.
>

Hi, just changed the remaining links to // (except the external ones), it
should be fine now. Please let me know what is missing!

Luca

Re: [Bug 55808] File integrity verification using MD5 and SHA1

Posted by Luca Toscano <to...@gmail.com>.
2016-02-02 21:10 GMT+01:00 Tom Fredrik Blenning Klaussen <bf...@blenning.no>:

>
> Having reviewed the changes I think they're good, but not complete.
> The remaining http links should be changed to // .
> Eg "http://httpd.apache.org/mod_ftp/" should be changed to
> "//httpd.apache.org/mod_ftp/" for all links containing apache servers.
> I'm not sure if external links needs to be changed, but to the extent
> they work I see nothing wrong in changing them.
>

Hi, just changed the remaining links to // (except the external ones), it
should be fine now. Please let me know what is missing!

Luca

Re: [Bug 55808] File integrity verification using MD5 and SHA1

Posted by Tom Fredrik Blenning Klaussen <bf...@blenning.no>.

On 02/02/16 18:27, Luca Toscano wrote:
> Hi Yann,
> 
> sorry for the lack of response but I didn't notice the patch. I
> checked the links in staging and published the patch to 
> https://httpd.apache.org/download.cgi (hope that it is ok for
> you).
> 
> Thanks Tom!
> 
> Luca
> 
> 2016-02-02 11:09 GMT+01:00 Yann Ylavic <yl...@gmail.com>:
> 
>> On Wed, Jan 20, 2016 at 11:24 PM, Yann Ylavic
>> <yl...@gmail.com> wrote:
>>> 
>>> Would attached patch be appropriate, so that MD5/SHA1/ASC/KEYS
>>> files are under https://*.apache.org's certification?
>> 
>> Assuming lazy consensus, committed in r1728066.
>> 
>> Thanks Tom Fredrik.

Give credit where credit is due, nothing would have happened if it
hadn't been for Fedor Brunner's original report.

Having reviewed the changes I think they're good, but not complete.
The remaining http links should be changed to // .
Eg "http://httpd.apache.org/mod_ftp/" should be changed to
"//httpd.apache.org/mod_ftp/" for all links containing apache servers.
I'm not sure if external links needs to be changed, but to the extent
they work I see nothing wrong in changing them.

-Tom Fredrik

---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org


Re: [Bug 55808] File integrity verification using MD5 and SHA1

Posted by Luca Toscano <to...@gmail.com>.
Hi Yann,

sorry for the lack of response but I didn't notice the patch. I checked the
links in staging and published the patch to
https://httpd.apache.org/download.cgi (hope that it is ok for you).

Thanks Tom!

Luca

2016-02-02 11:09 GMT+01:00 Yann Ylavic <yl...@gmail.com>:

> On Wed, Jan 20, 2016 at 11:24 PM, Yann Ylavic <yl...@gmail.com>
> wrote:
> >
> > Would attached patch be appropriate, so that MD5/SHA1/ASC/KEYS files
> > are under https://*.apache.org's certification?
>
> Assuming lazy consensus, committed in r1728066.
>
> Thanks Tom Fredrik.
>
> Regards,
> Yann.
>

Re: [Bug 55808] File integrity verification using MD5 and SHA1

Posted by Luca Toscano <to...@gmail.com>.
Hi Yann,

sorry for the lack of response but I didn't notice the patch. I checked the
links in staging and published the patch to
https://httpd.apache.org/download.cgi (hope that it is ok for you).

Thanks Tom!

Luca

2016-02-02 11:09 GMT+01:00 Yann Ylavic <yl...@gmail.com>:

> On Wed, Jan 20, 2016 at 11:24 PM, Yann Ylavic <yl...@gmail.com>
> wrote:
> >
> > Would attached patch be appropriate, so that MD5/SHA1/ASC/KEYS files
> > are under https://*.apache.org's certification?
>
> Assuming lazy consensus, committed in r1728066.
>
> Thanks Tom Fredrik.
>
> Regards,
> Yann.
>

Re: [Bug 55808] File integrity verification using MD5 and SHA1

Posted by Yann Ylavic <yl...@gmail.com>.
On Wed, Jan 20, 2016 at 11:24 PM, Yann Ylavic <yl...@gmail.com> wrote:
>
> Would attached patch be appropriate, so that MD5/SHA1/ASC/KEYS files
> are under https://*.apache.org's certification?

Assuming lazy consensus, committed in r1728066.

Thanks Tom Fredrik.

Regards,
Yann.

Re: [Bug 55808] File integrity verification using MD5 and SHA1

Posted by Yann Ylavic <yl...@gmail.com>.
On Wed, Jan 20, 2016 at 11:24 PM, Yann Ylavic <yl...@gmail.com> wrote:
>
> Would attached patch be appropriate, so that MD5/SHA1/ASC/KEYS files
> are under https://*.apache.org's certification?

Assuming lazy consensus, committed in r1728066.

Thanks Tom Fredrik.

Regards,
Yann.

---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org


Re: [Bug 55808] File integrity verification using MD5 and SHA1

Posted by Yann Ylavic <yl...@gmail.com>.
On Thu, Jan 14, 2016 at 9:25 AM, Yann Ylavic <yl...@gmail.com> wrote:
> [cross posting @docs => @dev, full thread
> http://www.gossamer-threads.com/lists/apache/docs/453401]
>
> On Thu, Jan 14, 2016 at 1:50 AM, Tom Fredrik Blenning Klaussen
> <bf...@blenning.no> wrote:
>>
>> On 14/01/16 01:19, Yann Ylavic wrote:
>>>
>>> as I said earlier, the way you access the
>>> tarball is not that important provided you verify its signature, or
>>> its digests from the official repository only.
>>
>> I understand what you are saying that the proper way is to download
>> the checksums from the correct source, which is self-evident. Now
>> assume you're a new user, and do not have this previous knowledge.
>> This user is security conscious, so the user chooses https on purpose.
>> He would go into (https://httpd.apache.org), where he would find a
>> link taking him to (https://httpd.apache.org/download.cgi), at this
>> point, he would find the link to (http://www.apache.org/dist/httpd/),
>> what I'm saying is in order to have some trust in that link, it
>> _SHOULD_ be https otherwise assuming you could introduce yourself as a
>> MitM, manipulating the signatures would be trivial.
>
> OK, I thought the links to the MD5/SH1/PGP were https: but this is not the case.
> I agree that the origin of these files should be trustable.
>
> @dev: should I s/http:/https:/ for those links (only) in
> ^httpd/site/trunk/content/download.mdtext?
> Or possibly use paths instead (i.e. /dist/httpd/...) so that it
> depends on /download.cgi is accessed?
> Would that be enough for the prod to be updated (via staging)?

Would attached patch be appropriate, so that MD5/SHA1/ASC/KEYS files
are under https://*.apache.org's certification?

Re: [Bug 55808] File integrity verification using MD5 and SHA1

Posted by Yann Ylavic <yl...@gmail.com>.
On Thu, Jan 14, 2016 at 9:25 AM, Yann Ylavic <yl...@gmail.com> wrote:
> [cross posting @docs => @dev, full thread
> http://www.gossamer-threads.com/lists/apache/docs/453401]
>
> On Thu, Jan 14, 2016 at 1:50 AM, Tom Fredrik Blenning Klaussen
> <bf...@blenning.no> wrote:
>>
>> On 14/01/16 01:19, Yann Ylavic wrote:
>>>
>>> as I said earlier, the way you access the
>>> tarball is not that important provided you verify its signature, or
>>> its digests from the official repository only.
>>
>> I understand what you are saying that the proper way is to download
>> the checksums from the correct source, which is self-evident. Now
>> assume you're a new user, and do not have this previous knowledge.
>> This user is security conscious, so the user chooses https on purpose.
>> He would go into (https://httpd.apache.org), where he would find a
>> link taking him to (https://httpd.apache.org/download.cgi), at this
>> point, he would find the link to (http://www.apache.org/dist/httpd/),
>> what I'm saying is in order to have some trust in that link, it
>> _SHOULD_ be https otherwise assuming you could introduce yourself as a
>> MitM, manipulating the signatures would be trivial.
>
> OK, I thought the links to the MD5/SH1/PGP were https: but this is not the case.
> I agree that the origin of these files should be trustable.
>
> @dev: should I s/http:/https:/ for those links (only) in
> ^httpd/site/trunk/content/download.mdtext?
> Or possibly use paths instead (i.e. /dist/httpd/...) so that it
> depends on /download.cgi is accessed?
> Would that be enough for the prod to be updated (via staging)?

Would attached patch be appropriate, so that MD5/SHA1/ASC/KEYS files
are under https://*.apache.org's certification?