Re: [gentoo-user] Re: package download verification

[Alan McKinnon]

On 07/05/2014 16:12, James wrote:
> Alan McKinnon <alan.mckinnon <at> gmail.com> writes:
>
>
>>> This is retarded, and I'm too old to do that now, so I went shopping
>>> for some script/tool/code to do it for me. In fact, I do not know
>>> why the integrity check is not fully integrated into ftp. rsync.
>>> or whatever the download tool is?
>
>
>> Perhaps I'm just old and retarded myself, but portage already does what
>> you want.
>
>
> Well certainly portage is one common methods to download, and we can explore
> that thread. But, I was thinking more general. Late last night (too late) I
> decided to download 'lilblue'. I poked around on several gentoo mirrors and
> could not find it. So with my google hat on, I found it on a non typical
> (mirror) server. The download was slow (300K) so naturally, I became
> suspicious. I checked manually, but it was late and I was tired.....
>
>
> The download was kicked off from the web browser (seamonkey). Now that I
> think about it, there are a myriad of ways to download sources. What I was
> suggesting (inquiring?) is that a command line tool could be readily
> developed (if it did not already exist) to simple check any download
> against the published data (keys/hashes/etc) depending on what is in the
> local dir where the download lands (is stored). It could be used with
> protage files too.
> But why not just use a simple script:
>
> <scriptname> package.just.downloaded package.just.downloaded.DIGESTS
>
>
>
> But then I got to questioning the integrity of both the downloaded sources
> and the digest originating on the same server........ Probably not a good
> idea either? So the digest should come from elsewhere? Maybe pull the digest
> from a certificated (pontificated?) (gentoo controlled) server and not
> somebody's (low priority managed) public server. Or maybe a master list of
> digests (hashes) could be included on every (hardened) gentoo box?
>
>
>
> It seems *everything is hacked* now. Certainly the NSA has fessed up to that
> as have others.  Sure it may be just "good business" but the brightest minds
> now days are mostly focused on security comprimises, particularly offensive
> strategies, imho. So it seems to me, there is probably a "fly in the
> ointment" common to what everyone is doing on a semi regular basis. To me
> this sort of (justified/unjustified) paranoia should be incorporated into
> the entire "hardened" effort at gentoo, imho, if not on a wider basis.
>
>
> So please continue the "protage" thread discussion, but also a wider thread
> concerning other source downloads. Afterall, *if" you can inject* into
> sources, which are then compiled, who checks under the under_garments? If
> you read about "The rat" the most secure implementation had/has tainted it's
> very soul. [1]
>
>
>
> curiously,
> James
>
> [1]
> http://arstechnica.com/information-technology/2014/04/openssl-code-beyond-repair-claims-creator-of-libressl-fork/

Thanks, now I understand better the question you are asking.

I don't think it can be solved at all in the general case, for two reasons.

One, the internet and it's core protocols are inherently not worthy of
trust. There just isn't any way to prove that traffic is what it claims
to be and no crypto verification built into the core of it. You either
trust the traffic or you don't, but there's nothing inherent in the
traffic to help you decide. So, all the download protocols have security
checking bolted on afterwards by individual apps. These apps may or may
not be compatible with each other and may or may not do their checks
similarly from one protocol to the next. Somebody would have to garner
enough support so that all the major projects doing file and data
transfers agree on some way to implement crypto checks. Good luck with
that :-) if they do agree on something, we have the second problem.

Internet downloads have an inherent problem - you download an unknown
bunch of bits from somewhere and can't fully trust the result. You can
check hashes against the downloaded file, but you have to get them from
somewhere. And the method to get them is the same as getting the data
file itself - a bunch of bits from somewhere and you can't trust it. How
can you download trusted hash data from a source where you don't trust
the regular downloads? Can't work; two no trusts don't make a one trust.

And who's global hash store of all known hashes of all known
downloadables would you trust anyway? The NSAs? :-)

Best you can do is make something for the specific case. The Gentoo tree
and distfiles can be GPG signed and if you agree to trust Gentoo's keys
then you are good to go and it can be automated (which is the easy bit
btw).

For the general case/ I can't see that work at all. I trust Gentoo with
Gentoo, but I don't see myself ever trusting $ARB_3RD_PARTY with $EVERYTHING

-- 
Alan McKinnon
alan.mckinnon@×××××.com