>
> You mean the source files that you downloaded and then hashed...
>
Yes. If the source files are being modified via a MITM attack (which is
trivial if the host uses HTTP) the checksum is still useful.
On Sat, Dec 3, 2016 at 6:27 AM, fnodeuser wrote:
> https://lists.archlinux.org/pipermail/arch-dev-public/2016-November/028492.html
I would suggest considering TUF - The Update Framework or stealing their
signing scheme which withstands all kinds of attack scenarios.
Before you discuss it further, Ralf and piequiex, I did announce using
bofh excuses earlier in this thread.
I actually pulled the part with Germany randoly from collection of bofh excuses.
None of any of that was real.
We're having extreme gravity fluctuations, please move your pc to the
floor rap
> On Sat, 3 Dec 2016 00:30:43 + (GMT), piequiex wrote:
> >> give some context and some information about what you upgraded, what
> >> you were doing when it happened and what software was running.
> >> Looking
> >Read original message.
> >On boot.
>
> I need to correct Martin, only your mai
> On Fri, 2 Dec 2016 17:25:57 + (GMT)
> piequiex wrote:
> > > Have a nice day!
> > >
> > >
> > > You too!
> > Useless message.
> > P.S. Adjust MUA setings.
>
> Just as useless as you original message.
Then do not waste time on my useless message.
--
Have a nice day!
Am 03.12.2016 um 20:07 schrieb Maxwell Anselm via arch-general:
>>
>> I agree that we should use a strong hash by default where it makes
>> sense. But in the absense ob effective validation of upstream packages,
>> this is meaningless.
>>
>
> It would at least indicate that the source file has b
> On Sat, 3 Dec 2016 00:30:43 + (GMT)
> piequiex wrote:
>
> > > Whatever you expected to happen. I'm going to go through a few things
> > The logical conclusion.
>
> Logical conclusion: It crashed. What more do you want us to say? We're not
> kernel devs.
Perfect conclusion!
Advice?
--
>
> I agree that we should use a strong hash by default where it makes
> sense. But in the absense ob effective validation of upstream packages,
> this is meaningless.
>
It would at least indicate that the source file has been tampered with in
some way. Even though there would be no way to know th
Am 03.12.2016 um 06:27 schrieb fnodeuser:
>
> if an upstream does not sign the files, does not have https enabled, and/or
> refuses to take security and privacy seriously, sha512 must be used in the
> PKGBUILD files.
But using and hash value without the possibility to verify the hashed
files
> if an upstream does not sign the files, does not have https enabled, and/or
> refuses to take security and privacy seriously, sha512 must be used in the
> PKGBUILD files.
Then
1) you could argue our using SHA512 is meaningless, but
2) it doesn't matter; we should still be doing the Right™
On 12/02/16 at 05:47am, piequiex wrote:
> -BEGIN PGP SIGNED MESSAGE-
> [ 65.955101] BUG: unable to handle kernel paging request at 81e0
Welp, sounds like you a kernel bug, either the kernel just locked up or
hit a BUG_ON().
> [ 65.956510] IP: [] __memmove+0x24/0x1a0
> [ 6
On Sat, 3 Dec 2016 00:30:43 + (GMT), piequiex wrote:
>> give some context and some information about what you upgraded, what
>> you were doing when it happened and what software was running.
>> Looking
>Read original message.
>On boot.
I need to correct Martin, only your mails are censored:
12 matches
Mail list logo
