Re: golang-go.crypto / CVE-2019-11841

2020-11-15 Thread Brian May
Brian May writes: > I have contacted ftp-master concerning rclone. Waiting a response. Still no response. I submitted a bug report: https://bugs.debian.org/974877 -- Brian May

Re: golang-go.crypto / CVE-2019-11841

2020-11-10 Thread Brian May
Paul Wise writes: > It documents which source package versions need to be shipped to > ensure license compliance. > > https://www.debian.org/doc/debian-policy/ch-relationships.html#additional-source-packages-used-to-build-the-binary-built-using > > Please note that golang folks were/are using it

Re: golang-go.crypto / CVE-2019-11841

2020-11-09 Thread Paul Wise
On Mon, Nov 9, 2020 at 10:33 PM Brian May wrote: > What is this "Built-Using" header? It documents which source package versions need to be shipped to ensure license compliance. https://www.debian.org/doc/debian-policy/ch-relationships.html#additional-source-packages-used-to-build-the-binary-bui

Re: golang-go.crypto / CVE-2019-11841

2020-11-09 Thread Utkarsh Gupta
Hi Brian, On Tue, Nov 10, 2020 at 4:03 AM Brian May wrote: > I might need help here: > > === cut === > Debian FTP Masters (28 mins. ago) () > Subject: rclone_1.35-1+deb8u1_amd64.changes REJECTED > To: d...@security.debian.org, b...@debian.org > Date: Mon, 09 Nov 2020 21:50:14 + > > golang-gi

Re: golang-go.crypto / CVE-2019-11841

2020-11-09 Thread Brian May
Brian May writes: > What is the process for rebuilding these in stretch LTS? Do I need to > add entries to dla-needed.txt and claim these entries? I might need help here: === cut === Debian FTP Masters (28 mins. ago) () Subject: rclone_1.35-1+deb8u1_amd64.changes REJECTED To: d...@security.deb

Re: golang-go.crypto / CVE-2019-11841

2020-11-08 Thread Utkarsh Gupta
Hi, On Mon, Nov 9, 2020 at 4:02 AM Brian May wrote: > What is the process for rebuilding these in stretch LTS? Do I need to > add entries to dla-needed.txt and claim these entries? Indeed, it's better and organized this way. I've CCed Thorsten (who's in charge of Front Desk this week!) so I thin

Re: golang-go.crypto / CVE-2019-11841

2020-11-08 Thread Brian May
Brian May writes: > This produced the following output to STDOUT: > > === cut === > obfs4proxy salsa20 > packer ssh/keys > rclone salsa20 > restic ssh/keys > snapd salsa20 > === cut === snapd seems to reproduce test failures, even without my security updates. :-( What is the process for reb

Re: golang-go.crypto / CVE-2019-11841

2020-11-04 Thread Brian May
Brian May writes: > Package: acmetool > Package: chasquid > Package: coyim > Package: go-wire > Package: gocryptfs > Package: golang-github-azure-azure-sdk-for-go > Package: golang-github-azure-go-autorest > Package: golang-github-azure-go-ntlmssp > Package: golang-github-bowery-prompt > Package:

Re: golang-go.crypto / CVE-2019-11841

2020-10-11 Thread Brian May
Emilio Pozuelo Monfort writes: > I would look for an automated way to do this. E.g. by downloading and > inspecting > the binaries to see if they have the affected code. Hmmm. Good idea in theory, but not sure how to do this in practise. I tried building two copies of acmetool, and comparing,

Re: golang-go.crypto / CVE-2019-11841

2020-10-11 Thread Adrian Bunk
On Fri, Oct 09, 2020 at 12:17:26PM +0200, Emilio Pozuelo Monfort wrote: > On 09/10/2020 00:23, Brian May wrote: > > We probably need someway of keeping track of what packages have already > > been looked at and their status with respect to this rebuild. Not really > > convinced data/dla-needed.txt

Re: golang-go.crypto / CVE-2019-11841

2020-10-09 Thread Emilio Pozuelo Monfort
On 09/10/2020 00:23, Brian May wrote: We probably need someway of keeping track of what packages have already been looked at and their status with respect to this rebuild. Not really convinced data/dla-needed.txt is up to this task. I would look for an automated way to do this. E.g. by download

Re: golang-go.crypto / CVE-2019-11841

2020-10-08 Thread Brian May
Emilio Pozuelo Monfort writes: > That go be a simplification. However there's a chance one of those golang- > packages also has a bin package with a real binary, and then that may need to > be > rebuilt as well. > > Also, not all packages with compiled binaries necessarily need a rebuild. > E

Re: golang-go.crypto / CVE-2019-11841

2020-10-08 Thread Emilio Pozuelo Monfort
On 08/10/2020 10:30, Brian May wrote: Emilio Pozuelo Monfort writes: Note that many of those are golang modules which only ship go code on the -dev package, and thus don't need a rebuild. OTOH, compiled binaries may need a rebuild if they use the affected code (directly or indirectly). How d

Re: golang-go.crypto / CVE-2019-11841

2020-10-08 Thread Brian May
Emilio Pozuelo Monfort writes: > Note that many of those are golang modules which only ship go code on the > -dev > package, and thus don't need a rebuild. OTOH, compiled binaries may need a > rebuild if they use the affected code (directly or indirectly). How do I tell which ones need rebuil

Re: golang-go.crypto / CVE-2019-11841

2020-10-08 Thread Emilio Pozuelo Monfort
On 08/10/2020 10:08, Brian May wrote: Emilio Pozuelo Monfort writes: Have you checked if any rdeps need to be rebuilt? No. I imagine there might be some. How do I check? I can't remember right now how to check reverse build depends. root@andromeda:/# grep-dctrl -FBuild-Depends 'golang-gol

Re: golang-go.crypto / CVE-2019-11841

2020-10-08 Thread Utkarsh Gupta
Hi, On Thu, Oct 8, 2020 at 1:38 PM Brian May wrote: > No. I imagine there might be some. How do I check? I can't remember > right now how to check reverse build depends. reverse-depends $binary reverse-depends -b $binary - u

Re: golang-go.crypto / CVE-2019-11841

2020-10-08 Thread Brian May
Emilio Pozuelo Monfort writes: > Have you checked if any rdeps need to be rebuilt? No. I imagine there might be some. How do I check? I can't remember right now how to check reverse build depends. -- Brian May

Re: golang-go.crypto / CVE-2019-11841

2020-10-08 Thread Emilio Pozuelo Monfort
Hi, On 06/10/2020 23:42, Brian May wrote: Utkarsh Gupta writes: Ah, great. It'd nice to include this then! :) Done. See attached patch. I had to apply it manually, because patch was misapplying one of the hunks in the wrong place. There were several hunks that apply to SKEd25519 public key

Re: golang-go.crypto / CVE-2019-11841

2020-10-06 Thread Utkarsh Gupta
Hi Brian, On Wed, Oct 7, 2020 at 3:13 AM Brian May wrote: > Done. See attached patch. I had to apply it manually, because patch was > misapplying one of the hunks in the wrong place. There were several > hunks that apply to SKEd25519 public key stuff I skipped also because > this version does not

Re: golang-go.crypto / CVE-2019-11841

2020-10-06 Thread Brian May
Utkarsh Gupta writes: > Ah, great. It'd nice to include this then! :) Done. See attached patch. I had to apply it manually, because patch was misapplying one of the hunks in the wrong place. There were several hunks that apply to SKEd25519 public key stuff I skipped also because this version doe

Re: golang-go.crypto / CVE-2019-11841

2020-10-04 Thread Utkarsh Gupta
Hi Brian, On Mon, Oct 5, 2020 at 3:35 AM Brian May wrote: > I wasn't sure it was going to be worth it? Maybe not for an independent DLA but we could always piggyback them along with the ones that do. (at least that's my opinion!) > $ patch --dry-run -p1 < ../CVE-2020-9283.patch > checking file

Re: golang-go.crypto / CVE-2019-11841

2020-10-04 Thread Brian May
Utkarsh Gupta writes: > On Mon, Oct 5, 2020 at 3:03 AM Brian May wrote: >> I also had a look at CVE-2020-9283 (no DSA) - an invalid public key can >> cause a panic - however I feel this is not really a security issue. > > But still, in case you can include a fix for this in this upload, > that'd

Re: golang-go.crypto / CVE-2019-11841

2020-10-04 Thread Utkarsh Gupta
Hi Brian, Thanks for your work! On Mon, Oct 5, 2020 at 3:03 AM Brian May wrote: > I also had a look at CVE-2020-9283 (no DSA) - an invalid public key can > cause a panic - however I feel this is not really a security issue. But still, in case you can include a fix for this in this upload, that'

Re: golang-go.crypto / CVE-2019-11841

2020-10-04 Thread Brian May
Attached is my patch for golang-go.crypto which I intend to upload tomorrow for: * CVE-2019-11840 * CVE-2019-11841 I also had a look at CVE-2020-9283 (no DSA) - an invalid public key can cause a panic - however I feel this is not really a security issue. -- Brian May diff -Nru golang-go.crypto-

Re: golang-go.crypto / CVE-2019-11841

2020-09-14 Thread Ola Lundqvist
Hi So the header is not signed. Good to know. I think we can ignore the spoofing issue. Yes it is possible to spoof it but on the other hand you can just omit it even if it is checked. I think this is a minor issue. If at all an issue. But as always I may have missed some important point. The i

Re: golang-go.crypto / CVE-2019-11841

2020-09-13 Thread Brian May
Ola Lundqvist writes: > Looking at the code and your email I have some concerns. > > Isn't the header part of the "signed" argument? If it is not, then there is > no point of checking it since you can then just change the header anyway. > If it is part of the signed message it is possible for the

Re: golang-go.crypto / CVE-2019-11841

2020-09-11 Thread Ola Lundqvist
Hi Brian Looking at the code and your email I have some concerns. Isn't the header part of the "signed" argument? If it is not, then there is no point of checking it since you can then just change the header anyway. If it is part of the signed message it is possible for the function to decode it

Re: golang-go.crypto / CVE-2019-11841

2020-09-09 Thread Brian May
Ola Lundqvist writes: > Do we have an idea on how a good patch would look like? OK, I think a patch may not be as simple as I hoped. CheckDetachedSignature() is where we decode the packet and determine the hash function used. But this function is not supplied the headers so it cannot check the

Re: golang-go.crypto / CVE-2019-11841

2020-09-09 Thread Ola Lundqvist
Hi Brian Yes it is not that good that we mark the issue as fixed. The question is how we convince upstream that this is actually a problem. Do we have an idea on how a good patch would look like? If we are close to fixing the issue we can just wait and then issue a new DLA-xxx-2 where we update

Re: golang-go.crypto / CVE-2019-11841

2020-09-08 Thread Brian May
Ola Lundqvist writes: > I agree with you about the hash part (the main part of it) of this CVE. In > fact this CVE is about two different things. If gnupg do hash validation I > think go should do the same. It concerns me that we have marked CVE-2019-11841 as resolved in bullseye and sid, and we

Re: golang-go.crypto / CVE-2019-11841

2020-09-08 Thread Ola Lundqvist
Hi Brian I agree with you about the hash part (the main part of it) of this CVE. In fact this CVE is about two different things. If gnupg do hash validation I think go should do the same. I was referring to the second part of the vulnerability described in "Moreover, since...". Now when I read ab

Re: golang-go.crypto / CVE-2019-11841

2020-09-07 Thread Brian May
Ola Lundqvist writes: > To completely fix the second part of this CVE I think an API change is > necessary. > The API need to return a list of unsigned and signed portions of the > message so the application using it can make it visible what parts are > signed and what parts are not. > However su

Re: golang-go.crypto / CVE-2019-11841

2020-09-07 Thread Ola Lundqvist
Hi again Also I think we need to consider the backwards compatibility of this. I guess there are quite a lot of emails with text before and after the signed text. If they will no longer be accepted this essentially means that the purpose of this function is pointless giving a less secure system th

Re: golang-go.crypto / CVE-2019-11841

2020-09-07 Thread Ola Lundqvist
Hi To completely fix the second part of this CVE I think an API change is necessary. The API need to return a list of unsigned and signed portions of the message so the application using it can make it visible what parts are signed and what parts are not. However such a change is large and cannot

Re: golang-go.crypto / CVE-2019-11841

2020-09-06 Thread Brian May
Attached is my patch for Stretch, based on the upstream patch. I am a bit uneasy about applying this and marking CVE-2019-11841 as fixed, because contrary to what upstream say I don't think CVE-2019-11841 is actually fixed. From the CVE description: [...] However, the Go clearsign package ign

Re: golang-go.crypto / CVE-2019-11841

2020-09-03 Thread Brian May
Brian May writes: > Brian May writes: > >> All of the distributions fail (as in the last two tests pass when they >> should now), but bullseye at least fixes one of the failures. So it >> looks like this was incorrectly marked as fixed (note bulleye and sid >> have the same version of this packa

Re: golang-go.crypto / CVE-2019-11841

2020-09-02 Thread Brian May
Brian May writes: > All of the distributions fail (as in the last two tests pass when they > should now), but bullseye at least fixes one of the failures. So it > looks like this was incorrectly marked as fixed (note bulleye and sid > have the same version of this package). I filled an upstream

Re: golang-go.crypto / CVE-2019-11841

2020-09-01 Thread Brian May
Brian May writes: > My attempts to run the reproducer program have not been successful, as > *none* of the signatures validate. Not even the known good case. I worked it out. The source had: -BEGIN PGP PUBLIC KEY BLOCK- mQENBFyeB6MBCAC+X0+7sQkrpg4zjQGj9NQSwPvDV5JjWxIXpf1n+mtrZewO8Rv

golang-go.crypto / CVE-2019-11841

2020-08-31 Thread Brian May
My attempts to run the reproducer program have not been successful, as *none* of the signatures validate. Not even the known good case. $ GOPATH=/usr/share/gocode/ go run sig_spoof.go Verifying not tampered... openpgp: invalid argument: no armored data found Verifying spoofed hash... openpgp: inva