Re: [arch-general] Harassment by David Runge
On 05/12, Marc Lehmann wrote: > Actually, from the reference you provide, this seems to be exactly _not_ > the case. I'm certainly no expert in arch packaging, but it looks as if > the arch package needs to explicitly add any gnupg signature files to the > source array, otherwise they wouldn't be checked. > > I can't find anything in the documentation that would indicate that > the existance of a .sig file on the server would trigger a mandatory, > unavoidable check. Correct, I was only talking about .sig files that the build system can actually see, i.e. are part of the source array. makepkg doesn't download files you don't tell it to, that would be quite insane indeed. Sorry for the confusion. Regards, Tharre -- PGP fingerprint: 42CE 7698 D6A0 6129 AA16 EF5C 5431 BDE2 C8F0 B2F4 signature.asc Description: PGP signature
Re: [arch-general] Harassment by David Runge
For clarity, On 05/11, Marc Lehmann via arch-general wrote: > He replied that the arch build system automatically treats all .sig files > as gpg signatures, and that this can't be switched off; that the signature > for http://dist.schmorp.de/liblzf/liblzf-3.6.tar.gz does not verify, and > claimed this affects all of the file signatures. This is indeed the case, see [0]. > I in turn replied that I consider this a candidate for a bug report > against the arch build system, as it shouldn't enforce treatment of > random .sig file as gpg signature. I also pointed out that it is a > security bug if arch linux treats .sig files without a hardcoded or > otherwise authenticated gpg key id, and shouldn't rely on a random > openpgp signature, even if that signature verifies. I did mention that > I can hardly imagine that the arch build system would be that broken > however. But this part is not, i.e. makepkg will only accept signatures from key(s) whose fingerprint are specified in validpgpkeys, and will not accept other random signatures. So there is no security issue here. I hope that was helpful. Regards, Tharre [0] https://wiki.archlinux.org/index.php/PKGBUILD#Sources -- PGP fingerprint: 42CE 7698 D6A0 6129 AA16 EF5C 5431 BDE2 C8F0 B2F4 signature.asc Description: PGP signature
Re: [arch-general] Kernel source URL change
On 08/08, Geo Kozey via arch-general wrote: > There is no tradition in Arch to self-host package sources as Debian does > unless upstream has > completely broken release process. This can impose security risks on Arch as > we now have to > trust their github infra rather than kernel.org (we all know what happened to > gentoo recently). > I'm aware that Barthalion made an effort to hardenize Arch github infra but > still this is a new risk > which didn't exist before. [...] > The point was that before changes no user had to care about > https://github.com/Archlinux > and now it's critical infrastructure for self-hosting package sources. No, nobody has to trust github or for that fact kernel.org. The commits/tags are *signed* and thus makepkg will check if that signature matches one of those specified in the validpgpkeys array. From a security standpoint, it's irrelevant if the sources come from arch hosted infra, from github, or from kernel.org. Regards, Tharre -- PGP fingerprint: 42CE 7698 D6A0 6129 AA16 EF5C 5431 BDE2 C8F0 B2F4 signature.asc Description: PGP signature
Re: [arch-general] Kernel source URL change
On 08/01, Andrey Vihrov via arch-general wrote: > - Previously the list of applied patches was very transparent. You could > immediately see that the kernel and kernel patch tarballs come from > kernel.org, and view individual extra patches. Now the code comes from a > non-kernel source, and cannot be verified as easily. Just run `git log v$_srcver`. That will show you all the patches that have been applied to the upstream release. That the sources do no longer come from kernel.org is irrelevant, you should _always_ verify the gpg signature for auditing purposes. > - Previously, if a new kernel version is released and is not yet in the > repos, you could more or less take the official linux PKGBUILD, change > one number and build it yourself. With the new layout it is not clear > how to achieve this. git-rebase(1) will accomplish that. > - An often cited Arch policy is to use software as released by upstream > with minimal patching. What becomes of this policy if one of the core > packages builds from a technical fork instead of upstream? Nobody forked the linux kernel, and no new patches have been added. The resulting package is exactly the same, so nothing changed in that regard. Regards, Tharre -- PGP fingerprint: 42CE 7698 D6A0 6129 AA16 EF5C 5431 BDE2 C8F0 B2F4 signature.asc Description: PGP signature
