On Mon, Jun 25, 2018, at 10:56 AM, Rolf Eike Beer wrote: > Ben Cooksley wrote: > > On Mon, Jun 25, 2018 at 6:57 PM, Rolf Eike Beer > > <[email protected]> wrote: > >> Am 2018-06-24 22:56, schrieb Albert Astals Cid: > >>> > >>> Hi, would anyone be against limiting who can create > >>> v${NUMBER}.${NUMBER}.${NUMBER} > >>> i.e. tags that look like our release tags to members of the release > >>> team > >>> for > >>> the KDE Applications git repositories? > >>> > >>> Rationale: Some distros build from git tags so creating a "release > >>> looking > >>> tag" is for them like "using the release tarball" and we already > >>> limit who > >>> can > >>> upload release tarballs to the download.kde.org so it would be a > >>> similar > >>> restriction but for the git side. > >> > >> > >> This sounds sane to me. Simply require those tags to be signed by > >> $key_in_known_good_list. > > > > Given the recent security issues surrounding interaction with GPG done > > by external programs, I would rather not perform key verification. > > Which one do you mean? The EFFfail one, that was about tricking mail > clients into data exfiltration (which is not relevant here)? The one > where the embedded filename was not properly sanitized (CVE-2018-12020) > and every distro should already have a patch deployed? Or the side > channel attacks to recover the private key that is not on the git > machine at all? > > Sorry, but not doing GnuPG is always the worse option. >
Having looked at the EFAIL vulnerability in particular I agree I see no reason to not do key verification. Any processing in principle has potential for vulnerabilities, but verifying a signature with a public key is IMO not any more dangerous than any other arbitrary operation or script. Cheers, Christian
