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
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
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
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
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
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
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
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:
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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'
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-
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
39 matches
Mail list logo