Re: Firmware-nonfree update?

[Utkarsh Gupta]

Hello,

On Mon, May 17, 2021 at 1:00 PM Ola Lundqvist  wrote:
> firmware-nonfree
>   NOTE: 20201207: wait for the update in buster and backport that (Emilio)
>
> The problem here is that will likely not happen due to the following note in 
> the security tracker on all the connected CVEs:
> [buster] - firmware-nonfree  (Non-free not supported)

This update should happen via -pu, IIUC. The cycle should roughly be:
sid -> (after migration to testing) buster-pu -> stretch-security ->
jessie-security.

Either the maintainer does the -pu or we do. If we're the ones doing
it, then this should be at least discussed with the maintainer.


- u

Re: Upgrade problems from LTS -> LTS+1

[Holger Levsen]

On Mon, May 17, 2021 at 01:09:10PM +0530, Utkarsh Gupta wrote:
> This shouldn't just run once, it should keep checking once in a while.
> And once especially when we're nearing EOL of the LTS and ELTS releases.
 
yes.

I'd be glad to setup such a script running regularly on jenkins.debian.net
and then to notify #debian-lts on irc and/or this mailing list (or
some other address/). I'd just need this script. ;)


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

"... the premise [is] that privacy is about hiding a wrong. It's not.
 Privacy is an inherent human right, and a requirement for maintaining
 the human condition with dignity and respect." (Bruce Schneier)


signature.asc
Description: PGP signature

Re: Best way forward for CVE-2021-22876/curl?

[Sylvain Beucler]

Hi,

I thought you'd rebuild but here you go.

I intend to upload today.

Cheers!
Sylvain

On 17/05/2021 08:13, Ola Lundqvist wrote:

Hi again Sylvain

Today I was about to test the packages but I realize that I only have a 
libcurl-doc deb file to test.


Will you upload the rest for testing too?

// Ola

On Sun, 16 May 2021 at 09:08, Ola Lundqvist > wrote:


Hi

I have reviewed the changes and it looks good.
I'll see if I can get some time to perform any relevant tests too.

// Ola

On Sat, 15 May 2021 at 23:34, Sylvain Beucler mailto:b...@beuc.net>> wrote:

Hi Ola,

You can check the LTS version at:
https://www.beuc.net/tmp/debian-lts/curl/


I followed the method from Ubuntu and SUSE and backported the
URL API
for LTS and ELTS, plus the new test case for the CVE.

I'm currently diffing the test suite results, cf. my notes at:
https://wiki.debian.org/LTS/TestSuites/curl


Cheers!
Sylvain

On 15/05/2021 23:22, Ola Lundqvist wrote:
 > Hi Sylvain
 >
 > Great! Let me know if you want help with review, testing or
something else.
 >
 > // Ola
 >
 > On Sat, 15 May 2021 at 23:18, Sylvain Beucler mailto:b...@beuc.net>
 > >> wrote:
 >
 >     Hi,
 >
 >     I claimed it yesterday and my work is mostly done.
 >
 >     Cheers!
 >     Sylvain
 >
 >     On 15/05/2021 23:11, Ola Lundqvist wrote:
 >      > Hi Utkarsh
 >      >
 >      > I have looked into your patch and I think it looks
good. I do not
 >     fully
 >      > understand why all the changes in url.c were done but
I think it
 >     looks
 >      > fine anyway.
 >      > The risk of regression should be small.
 >      >
 >      > Do you want me to do the update, or do you want to do
it yourself?
 >      > Or do you think we should ignore it?
 >      >
 >      > Best regards
 >      >
 >      > // Ola
 >      >
 >      > On Thu, 8 Apr 2021 at 22:33, Ola Lundqvist
mailto:o...@inguza.com>
 >     >
 >      > 
      >
 >      >     Hi Utkarsh, all
 >      >
 >      >     I have done some more investigation on this
matter. I have
 >     checked
 >      >     the statement from upstream that we can re-use
some existing
 >     strip
 >      >     code to remove the strings this way.
 >      >     The thing is that I cannot find any code that do
URL stripping so
 >      >     that is not really a viable option. This leaves
only the two
 >     options
 >      >     you have already stated.
 >      >
 >      >     Either we ignore, or we port the entire URL API.
 >      >
 >      >     I think the risk of regression is rather small if
we port it,
 >      >     because this is only used in this place. Assuming
there is no
 >     name
 >      >     clash introduced.
 >      >
 >      >     So what do you all think? Ignore or fix?
 >      >     There are good arguments for both.
 >      >
 >      >     Ignore is ok because this only happens with a specific
 >     command line
 >      >     option, and even if used the risk of problem is
quite small.
 >      >
 >      >     On the other hand curl is a very common tool which
means that it
 >      >     could be worth fixing even small issues.
 >      >
 >      >     I think both are ok.
 >      >
 >      >     Best regards
 >      >
 >      >     // Ola
 >      >
 >      >     On Wed, 7 Apr 2021 at 23:07, Ola Lundqvist
mailto:o...@inguza.com>
 >     >
 >      >     
      >
 >      >         Hi Utkarsh, all
 >      >
 >      >         After reading the description of this CVE
again I realize
 >     that I
 >      >         misunderstood the description last time.
 >      >
 >      >         The problem is that the "referrer" header is
not stripped.

Golang packages

[Ola Lundqvist]

Hi fellow LTS contributors

I have a question about go package support.

The question is whether we should try to support it in LTS or not:
According to this we do not give security support for go packages in
buster.
https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#golang-static-linking

There is also a discussion thread about adding this kind of information
to debian-security-support package, but there are concerns about wildcards
being a little too noisy.

I can also see a note in dla-needed for Thorsten working on automating go
updates.

My thinking is that we should remove these packages from dla-needed.txt
file and mark the CVE entries as EOL.

Alternatively make some statement that we do in fact intend to make these
updates even though they are not done for buster. Buf in that case, what is
the motivation for making such updates for oldstable when there is no plan
to do is for stable.

What do you think?

Cheers

// Mvh Ola

-- 
 --- Inguza Technology AB --- MSc in Information Technology 
|  o...@inguza.como...@debian.org|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
 ---

Re: Upgrade problems from LTS -> LTS+1

[Ola Lundqvist]

Hi

Should we try to automate the detection of such issues? It should be fairly
easy to do.
Package renaming complicates the checks but on the other hand if the
package is renamed the issue is not as big anymore.

// Ola

On Sun, 16 May 2021 at 10:55, Holger Levsen  wrote:

> On Sat, May 15, 2021 at 05:53:15PM +0530, Utkarsh Gupta wrote:
> > Whilst I'll fix this for stretch (already sponsored the upload for
> > buster), there are more such bugs for stretch -> buster (eg: [1] (->
> > fixed already), etc. Maybe we should keep an eye on such issues and
> > while we're doing DLAs, we can take care of -pu uploads, at least if
> > the versions are the same for LTS and LTS+1 so we don't run into
> > these?
>
> yes, please.
>
> else (if we break upgrades like this) LTS will start looking at lot less
> good :(
>
>
> --
> cheers,
> Holger
>
>  ⢀⣴⠾⠻⢶⣦⠀
>  ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
>  ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
>  ⠈⠳⣄
>


-- 
 --- Inguza Technology AB --- MSc in Information Technology 
|  o...@inguza.como...@debian.org|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
 ---

Re: Upgrade problems from LTS -> LTS+1

[Utkarsh Gupta]

On Mon, May 17, 2021 at 2:18 PM Utkarsh Gupta  wrote:
> I think we shouldn't wait for when the package in the older release
> has a greater version but check them *before*. [...]

Or well, we could check after as well. But I am much more inclined towards
"avoiding" such a problem in the first place, rather than trying to
fix it once it has
already happened.


- u

Re: Upgrade problems from LTS -> LTS+1

[Utkarsh Gupta]

Hello,

On Mon, May 17, 2021 at 2:05 PM Ola Lundqvist  wrote:
> 3) Merge the normal release with the security release (takes the latest)

Yeah, the goal is to cover all sorts of releases (normal, -pu, security) and
get the highest version amongst them.

> 4) Compare the two merged sets and check if the later release has any
> entry that is lower than the older release. Output those as "package version".

I think we shouldn't wait for when the package in the older release
has a greater version but check them *before*. That is, those packages
having the same version in ELTS & LTS or LTS & LTS+1 should be
flagged. This means, if they're added to {ela,dla}-needed, they should
either warrant a DSA upload or a -pu upload along with the DLA or ELA.
Hope that makes sense?



- u

Firmware-nonfree update?

[Ola Lundqvist]

Hi fellow LTS contributors

I noticed that firmware-nonfree has the following note in the
dla-needed.txt file.

firmware-nonfree
  NOTE: 20201207: wait for the update in buster and backport that (Emilio)

The problem here is that will likely not happen due to the following note
in the security tracker on all the connected CVEs:
[buster] - firmware-nonfree  (Non-free not supported)

As I understand we can therefore not wait for firmware-nonfree.

I see two options:
1) Declare firmware-nonfree as not supported
2) Do the update for buster too.

What are your thoughts?

Cheers

// Ola


-- 
 --- Inguza Technology AB --- MSc in Information Technology 
|  o...@inguza.como...@debian.org|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
 ---

Re: Upgrade problems from LTS -> LTS+1

[Holger Levsen]

On Mon, May 17, 2021 at 09:33:47AM +0200, Ola Lundqvist wrote:
> Should we try to automate the detection of such issues? It should be fairly
> easy to do.

yes, please.

> Package renaming complicates the checks but on the other hand if the
> package is renamed the issue is not as big anymore.

yes, indeed :)


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄


signature.asc
Description: PGP signature

Re: Upgrade problems from LTS -> LTS+1

[Ola Lundqvist]

Hi

These are my thoughts on how the script would work:
1) Run the script with the following inputs:
- older release apt packages file
- older security release apt packages file
- later release apt packages file
- later security release apt package file
2) The script will then parse those files (looks for package and version)
3) Merge the normal release with the security release (takes the latest)
4) Compare the two merged sets and check if the later release has any entry
that is lower than the older release. Output those as "package version".

Best regards

// Ola

On Mon, 17 May 2021 at 10:05, Holger Levsen  wrote:

> On Mon, May 17, 2021 at 01:09:10PM +0530, Utkarsh Gupta wrote:
> > This shouldn't just run once, it should keep checking once in a while.
> > And once especially when we're nearing EOL of the LTS and ELTS releases.
>
> yes.
>
> I'd be glad to setup such a script running regularly on jenkins.debian.net
> and then to notify #debian-lts on irc and/or this mailing list (or
> some other address/). I'd just need this script. ;)
>
>
> --
> cheers,
> Holger
>
>  ⢀⣴⠾⠻⢶⣦⠀
>  ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
>  ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
>  ⠈⠳⣄
>
> "... the premise [is] that privacy is about hiding a wrong. It's not.
>  Privacy is an inherent human right, and a requirement for maintaining
>  the human condition with dignity and respect." (Bruce Schneier)
>


-- 
 --- Inguza Technology AB --- MSc in Information Technology 
|  o...@inguza.como...@debian.org|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
 ---

Re: Upgrade problems from LTS -> LTS+1

[Ola Lundqvist]

Hi

Yes that makes sense. I can write some tool for that too. But now I'm
focusing on finding already existing problems. The script is almost ready.
I'm testing it right now.

// Ola

On Mon, 17 May 2021 at 10:49, Utkarsh Gupta  wrote:

> Hello,
>
> On Mon, May 17, 2021 at 2:05 PM Ola Lundqvist  wrote:
> > 3) Merge the normal release with the security release (takes the latest)
>
> Yeah, the goal is to cover all sorts of releases (normal, -pu, security)
> and
> get the highest version amongst them.
>
> > 4) Compare the two merged sets and check if the later release has any
> > entry that is lower than the older release. Output those as "package
> version".
>
> I think we shouldn't wait for when the package in the older release
> has a greater version but check them *before*. That is, those packages
> having the same version in ELTS & LTS or LTS & LTS+1 should be
> flagged. This means, if they're added to {ela,dla}-needed, they should
> either warrant a DSA upload or a -pu upload along with the DLA or ELA.
> Hope that makes sense?
>
>
>
> - u
>
>

-- 
 --- Inguza Technology AB --- MSc in Information Technology 
|  o...@inguza.como...@debian.org|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
 ---

Re: Upgrade problems from LTS -> LTS+1

[Ola Lundqvist]

Hi

I'll write a script that do the conversion. It should not take that long.

// Ola



On Mon, 17 May 2021 at 09:39, Utkarsh Gupta  wrote:

> Hello,
>
> On Mon, May 17, 2021 at 1:04 PM Ola Lundqvist  wrote:
> > Should we try to automate the detection of such issues? It should be
> fairly easy to do.
>
> This shouldn't just run once, it should keep checking once in a while.
> And once especially when we're nearing EOL of the LTS and ELTS releases.
>
>
> - u
>


-- 
 --- Inguza Technology AB --- MSc in Information Technology 
|  o...@inguza.como...@debian.org|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
 ---

Re: Best way forward for CVE-2021-22876/curl?

[Ola Lundqvist]

Hi again Sylvain

Today I was about to test the packages but I realize that I only have a
libcurl-doc deb file to test.

Will you upload the rest for testing too?

// Ola

On Sun, 16 May 2021 at 09:08, Ola Lundqvist  wrote:

> Hi
>
> I have reviewed the changes and it looks good.
> I'll see if I can get some time to perform any relevant tests too.
>
> // Ola
>
> On Sat, 15 May 2021 at 23:34, Sylvain Beucler  wrote:
>
>> Hi Ola,
>>
>> You can check the LTS version at:
>> https://www.beuc.net/tmp/debian-lts/curl/
>>
>> I followed the method from Ubuntu and SUSE and backported the URL API
>> for LTS and ELTS, plus the new test case for the CVE.
>>
>> I'm currently diffing the test suite results, cf. my notes at:
>> https://wiki.debian.org/LTS/TestSuites/curl
>>
>> Cheers!
>> Sylvain
>>
>> On 15/05/2021 23:22, Ola Lundqvist wrote:
>> > Hi Sylvain
>> >
>> > Great! Let me know if you want help with review, testing or something
>> else.
>> >
>> > // Ola
>> >
>> > On Sat, 15 May 2021 at 23:18, Sylvain Beucler > > > wrote:
>> >
>> > Hi,
>> >
>> > I claimed it yesterday and my work is mostly done.
>> >
>> > Cheers!
>> > Sylvain
>> >
>> > On 15/05/2021 23:11, Ola Lundqvist wrote:
>> >  > Hi Utkarsh
>> >  >
>> >  > I have looked into your patch and I think it looks good. I do not
>> > fully
>> >  > understand why all the changes in url.c were done but I think it
>> > looks
>> >  > fine anyway.
>> >  > The risk of regression should be small.
>> >  >
>> >  > Do you want me to do the update, or do you want to do it
>> yourself?
>> >  > Or do you think we should ignore it?
>> >  >
>> >  > Best regards
>> >  >
>> >  > // Ola
>> >  >
>> >  > On Thu, 8 Apr 2021 at 22:33, Ola Lundqvist > > 
>> >  > >> wrote:
>> >  >
>> >  > Hi Utkarsh, all
>> >  >
>> >  > I have done some more investigation on this matter. I have
>> > checked
>> >  > the statement from upstream that we can re-use some existing
>> > strip
>> >  > code to remove the strings this way.
>> >  > The thing is that I cannot find any code that do URL
>> stripping so
>> >  > that is not really a viable option. This leaves only the two
>> > options
>> >  > you have already stated.
>> >  >
>> >  > Either we ignore, or we port the entire URL API.
>> >  >
>> >  > I think the risk of regression is rather small if we port it,
>> >  > because this is only used in this place. Assuming there is no
>> > name
>> >  > clash introduced.
>> >  >
>> >  > So what do you all think? Ignore or fix?
>> >  > There are good arguments for both.
>> >  >
>> >  > Ignore is ok because this only happens with a specific
>> > command line
>> >  > option, and even if used the risk of problem is quite small.
>> >  >
>> >  > On the other hand curl is a very common tool which means
>> that it
>> >  > could be worth fixing even small issues.
>> >  >
>> >  > I think both are ok.
>> >  >
>> >  > Best regards
>> >  >
>> >  > // Ola
>> >  >
>> >  > On Wed, 7 Apr 2021 at 23:07, Ola Lundqvist > > 
>> >  > >> wrote:
>> >  >
>> >  > Hi Utkarsh, all
>> >  >
>> >  > After reading the description of this CVE again I realize
>> > that I
>> >  > misunderstood the description last time.
>> >  >
>> >  > The problem is that the "referrer" header is not
>> stripped.
>> >  >
>> >  > This changes my conclusion to some extent.
>> >  >
>> >  > I see no problem with fixing this issue from a regression
>> > point
>> >  > of view (apart from what has already been expressed).
>> >  > The amount of services that rely on the referrer field
>> > should be
>> >  > small, if any.
>> >  >
>> >  > I still think we can ignore it though with the
>> > same reasoing as
>> >  > I expressed in the last email. The problem should be
>> minor.
>> >  > There are other worse problem by providing sensitive data
>> > in the
>> >  > URL.
>> >  > And again if the attacker can make a redirect, the
>> > attacker can
>> >  > most likely get the URL anyway so then nothing has
>> leaked.
>> >  >
>> >  > Cheers
>> >  >
>> >  > // Ola
>> >  >
>> >  >
>> >  > // Ola
>> >  >
>> >  > On Wed, 7 Apr 2021 at 13:19, Ola Lundqvist
>> > mailto:o...@inguza.com>
>> >  > >> wrote:
>> >  >
>> >  > 

Re: Upgrade problems from LTS -> LTS+1

[Utkarsh Gupta]

Hello,

On Mon, May 17, 2021 at 1:04 PM Ola Lundqvist  wrote:
> Should we try to automate the detection of such issues? It should be fairly 
> easy to do.

This shouldn't just run once, it should keep checking once in a while.
And once especially when we're nearing EOL of the LTS and ELTS releases.


- u

Re: Best way forward for CVE-2021-22876/curl?

[Sylvain Beucler]

Thanks for the additional testing.
Uploaded.

Cheers!
Sylvain

On 17/05/2021 12:39, Ola Lundqvist wrote:

Hi again

I was able to reproduce the issue and I can confirm that it is  solved 
by the update.


On an unfixed version I run the following:
    curl -L -e ";auto" -raw -v http://test:p...@inguza.com/ 
'


And the resulting Referer output was:
 > Referer: http://test:p...@inguza.com/ 

With the fixed package I run the same command:
      curl -L -e ";auto" -raw -v http://test:p...@inguza.com/ 
'


And the resulting Referer output was correctly  stripped:
 > Referer: http://inguza.com/ 

Great!

So I think it looks good.

Best regards

// Ola


On Mon, 17 May 2021 at 12:30, Ola Lundqvist > wrote:


Hi Sylvain

I have done some regression testing and it looks fine.

I'll try to reproduce the actual issue too.

// Ola

On Mon, 17 May 2021 at 11:09, Sylvain Beucler mailto:b...@beuc.net>> wrote:

Hi,

I thought you'd rebuild but here you go.

I intend to upload today.

Cheers!
Sylvain

On 17/05/2021 08:13, Ola Lundqvist wrote:
 > Hi again Sylvain
 >
 > Today I was about to test the packages but I realize that I
only have a
 > libcurl-doc deb file to test.
 >
 > Will you upload the rest for testing too?
 >
 > // Ola
 >
 > On Sun, 16 May 2021 at 09:08, Ola Lundqvist mailto:o...@inguza.com>
 > >> wrote:
 >
 >     Hi
 >
 >     I have reviewed the changes and it looks good.
 >     I'll see if I can get some time to perform any relevant
tests too.
 >
 >     // Ola
 >
 >     On Sat, 15 May 2021 at 23:34, Sylvain Beucler
mailto:b...@beuc.net>
 >     >> wrote:
 >
 >         Hi Ola,
 >
 >         You can check the LTS version at:
 > https://www.beuc.net/tmp/debian-lts/curl/

 >         >
 >
 >         I followed the method from Ubuntu and SUSE and
backported the
 >         URL API
 >         for LTS and ELTS, plus the new test case for the CVE.
 >
 >         I'm currently diffing the test suite results, cf. my
notes at:
 > https://wiki.debian.org/LTS/TestSuites/curl

 >         >
 >
 >         Cheers!
 >         Sylvain
 >
 >         On 15/05/2021 23:22, Ola Lundqvist wrote:
 >          > Hi Sylvain
 >          >
 >          > Great! Let me know if you want help with review,
testing or
 >         something else.
 >          >
 >          > // Ola
 >          >
 >          > On Sat, 15 May 2021 at 23:18, Sylvain Beucler
mailto:b...@beuc.net>
 >         >
 >          > 
          >
 >          >     Hi,
 >          >
 >          >     I claimed it yesterday and my work is mostly done.
 >          >
 >          >     Cheers!
 >          >     Sylvain
 >          >
 >          >     On 15/05/2021 23:11, Ola Lundqvist wrote:
 >          >      > Hi Utkarsh
 >          >      >
 >          >      > I have looked into your patch and I think
it looks
 >         good. I do not
 >          >     fully
 >          >      > understand why all the changes in url.c
were done but
 >         I think it
 >          >     looks
 >          >      > fine anyway.
 >          >      > The risk of regression should be small.
 >          >      >
 >          >      > Do you want me to do the update, or do you
want to do
 >         it yourself?
 >          >      > Or do you think we should ignore it?
 >          >      >
 >          >      > Best regards
 >          >      >
 >          >      > // Ola
 >          >      >
 >          >      > On Thu, 8 Apr 2021 at 22:33, Ola Lundqvist
 >         mailto:o...@inguza.com>
>
 >          >     

[SECURITY] [DLA 2664-1] curl security update

[Sylvain Beucler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

- -
Debian LTS Advisory DLA-2664-1debian-...@lists.debian.org
https://www.debian.org/lts/security/  Sylvain Beucler
May 17, 2021  https://wiki.debian.org/LTS
- -

Package: curl
Version: 7.52.1-5+deb9u14
CVE ID : CVE-2021-22876
Debian Bug : 986269

Viktor Szakats reported that libcurl, an URL transfer library, does
not strip off user credentials from the URL when automatically
populating the Referer HTTP request header field in outgoing HTTP
requests. Sensitive authentication data may leak to the server that is
the target of the second HTTP request.

For Debian 9 stretch, this problem has been fixed in version
7.52.1-5+deb9u14.

We recommend that you upgrade your curl packages.

For the detailed security status of curl please refer to
its security tracker page at:
https://security-tracker.debian.org/tracker/curl

Further information about Debian LTS security advisories, how to apply
these updates to your system and frequently asked questions can be
found at: https://wiki.debian.org/LTS
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE1vEOfV7HXWKqBieIDTl9HeUlXjAFAmCifwYACgkQDTl9HeUl
XjBIzw//QUTAucSm3wA2RJQgLiDPMCf5m87S6tQgQOMZWjrNlUXZc41j/WrC5Dre
rhJQc5XLhuulpAts6PcLHyMD7ee8+GxdXmhc+i7BpWXQ5u/I9oFQsQFNpnk1s2Ug
RWXE8dnnDIB9PK5Zg9MI4/9/+L24pK2AJSAfqWjm4nASjI0iIPzNZ1Dg6cTl0Rg3
P5RwxsnuQ3vlM+4766V2+7TNqfE7xvsk/D5r8qxlisPaqTQmbY5KqHe2JKopxbk0
gIyaiQThZnfP6q44TYUfyu1HnqyCYzpwaPPyti/4s35x35NRpmH4mDFU29221JVA
1yMKFkYSPa0izFs/CmcSa8q3b0DF9FVCToI5mcGnrt9WdyDcwxmqGwGXT58UaWI6
3Bq5HzBJQ2FUvl42vXDGj44X5bmdstjUgNi0Xd3pqC1l0VqRYOms/F6mD2BL2VAu
8buzsx7+qosDbM7ZIWG02L5Khyps2OXFZ7MXIn/6MMXBKgN5aQbCKJxGajx0qw07
h1ngja7B3w6IzsL9Y8+7QnRNpUfwxKZ0sFOnvtGUM3mF2k2zMUyDKnROdpWc70Z1
Sl5gykPpxO4EC4KgXWjivMnirsMu6t4tnIcrwjTrZkUmVmEfJChD1qZ29splq5a/
BwZY4QK7LQV7KfW9jE5UaZBEt1JgwvMg+D9En/OCTQB4Sid7LX4=
=7ZhP
-END PGP SIGNATURE-

(semi-)automatic unclaim of packages with more than 2 weeks of inactivity (and missing DLAs on www.do)

[Lynoure Braakman]

hi,

Nobody claimed 4 packages or more.


Following package was unclaimed for LTS:
-ansible (Markus Koschany)


Here I'm having doubts about needing to unclaim this... Do take it back 
as you see fit, Markus.



Nothing was unclaimed for ELTS.


Only one reserved DLA has not been published yet:
 DLA 2664-1 (17 May 2021) (curl)


Have a good week, everybody!

--
Lynoure

Accepted curl 7.52.1-5+deb9u14 (source) into oldstable

[Debian FTP Masters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 15 May 2021 18:11:21 +0200
Source: curl
Binary: curl libcurl3 libcurl3-gnutls libcurl3-nss libcurl4-openssl-dev 
libcurl4-gnutls-dev libcurl4-nss-dev libcurl3-dbg libcurl4-doc
Architecture: source
Version: 7.52.1-5+deb9u14
Distribution: stretch-security
Urgency: high
Maintainer: Alessandro Ghedini 
Changed-By: Sylvain Beucler 
Description:
 curl   - command line tool for transferring data with URL syntax
 libcurl3   - easy-to-use client-side URL transfer library (OpenSSL flavour)
 libcurl3-dbg - debugging symbols for libcurl (OpenSSL, GnuTLS and NSS flavours)
 libcurl3-gnutls - easy-to-use client-side URL transfer library (GnuTLS flavour)
 libcurl3-nss - easy-to-use client-side URL transfer library (NSS flavour)
 libcurl4-doc - documentation for libcurl
 libcurl4-gnutls-dev - development files and documentation for libcurl (GnuTLS 
flavour)
 libcurl4-nss-dev - development files and documentation for libcurl (NSS 
flavour)
 libcurl4-openssl-dev - development files and documentation for libcurl 
(OpenSSL flavour)
Changes:
 curl (7.52.1-5+deb9u14) stretch-security; urgency=high
 .
   * Non-maintainer upload by the LTS Security Team.
   * Backport URL API which is a pre-requisite for CVE-2021-22876.
   * Reference new symbols.
   * CVE-2021-22876: curl is vulnerable to an "Exposure of Private Personal
 Information to an Unauthorized Actor" by leaking credentials in the
 HTTP Referer: header. libcurl does not strip off user credentials from
 the URL when automatically populating the Referer: HTTP request header
 field in outgoing HTTP requests, and therefore risks leaking sensitive
 data to the server that is the target of the second HTTP request.
Checksums-Sha1:
 1f7187f76558b43136aabc9a87b063a2127fb27f 2797 curl_7.52.1-5+deb9u14.dsc
 a081bd50e3865c83325c4f578f575c8d7829d205 62860 
curl_7.52.1-5+deb9u14.debian.tar.xz
 91dbe25cc2d8bdbcea4bcfcbbf5665734928515a 10776 
curl_7.52.1-5+deb9u14_amd64.buildinfo
Checksums-Sha256:
 eeddbe48282f5ce93ad24d3dd5a431ee294617e104d35ea274b38a0f09c2f568 2797 
curl_7.52.1-5+deb9u14.dsc
 1294a6c5f5411b05d4972b97b51b3a72cdc06f250f5d0ccdcf418c5cf3fab615 62860 
curl_7.52.1-5+deb9u14.debian.tar.xz
 ca81bb8ceca76c27b3301436501f0bcd488b2895c4c2223d968b0d9535565794 10776 
curl_7.52.1-5+deb9u14_amd64.buildinfo
Files:
 d50ae090b8c15710c4915263538c4a88 2797 web optional curl_7.52.1-5+deb9u14.dsc
 57b680fe19414e1e33352b9922adbe3a 62860 web optional 
curl_7.52.1-5+deb9u14.debian.tar.xz
 c6441044a9e3fadc49539ccc46f5c88f 10776 web optional 
curl_7.52.1-5+deb9u14_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE1vEOfV7HXWKqBieIDTl9HeUlXjAFAmCieNcACgkQDTl9HeUl
XjCL9Q//cNiei9GFr9JhPtrr5itBlMDUoujlIhefWDY0u2RAlV6qRbLtToUQFpiz
ovJmUplKHpUJsHddqd06yiWy5DCz5QhpiB+AbNnzUQ8Rw+Kw7L3gcQ8DFaMFdjzq
PcGVRdcSG57ehLpsdL1lw2toh+ZuyE/yI1IVygFsMatFhOD3INO/IaQckziNgbn7
ZsbrsNENG6SdQZOM0+QAB/OJRq5TXSUoAXSSw3yr/Ed6mMg2DE9+WQt16RaJuEhc
OlUPv/1TyjwlGGZGEbBKhBuWxYkX/ARFPZUWKwagZbvvjBx3EY/ph+G5MyPrYObY
TGR2MM1N6yDUYfMbyFlXZb5mngW9JUh7ZtBgyuYrqNdS9CKZSVpuHsUbt14hoD1z
afrG5Ch3lvGpIczKmmYmfrWQUMbq2wu41/kKMGi67QSlx64zPR9MXxuO8Ho8TD2P
t/nmY5E5ODfI+H7xuU7aBT1TbG+b7XpqCzLLgI9wuvvBH151YkVz3VgdhbUNIGls
o11UG6zQqCpV6WBvPFudhG5h0fVDmp3fQZt1Nt0ijvgIuqgxMTLaH/NdR+FCNZor
5KyOG/cTTLZj10t6sTczmq5XoJVpNsKmpznAqcivjkcwjnB/Az+h+dgMaNciuxMb
0H8K+M9mqlFyv1DqCe/HXL9U6Fq8pBTN9edtD0P1spoTGYttRW4=
=LKjW
-END PGP SIGNATURE-

Re: Upgrade problems from LTS -> LTS+1

[Holger Levsen]

On Mon, May 17, 2021 at 04:54:39PM +0530, Utkarsh Gupta wrote:
> > debian-security-support: 1:9+2021.01.23 newer than 2020.06.21~deb10u1
> Holger, can you TAL?

Gee...  I don't know what TAL means...

That said, I'm aware of this issue and have been waiting for an issue worth 
updating debian-security-support in buster. I don't think the version skew
alone is worth an update, *maybe* as part of a point release it
is.
 

-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

The upcoming clima apocalypse is the big elephant in every room now.


signature.asc
Description: PGP signature

Re: Upgrade problems from LTS -> LTS+1

[Abhijith PA]

On 17/05/21 04:54 PM, Utkarsh Gupta wrote:
> Hello,
> 
> On Mon, May 17, 2021 at 3:08 PM Ola Lundqvist  wrote:
> > mqtt-client: 1.14-1+deb9u1 newer than 1.14-1
> 
> Abhijith, can you please take care of this? You need a -pu update
> prepared for this.

Okay, I will take care of this. Issue is no DSA in buster. So I guess 
this will be in next point release.


--abhijith

Firmware-nonfree update for buster?

[Ola Lundqvist]

Hi firmware-nonfree maintainers

I have a question from an LTS perspective about the possible security
updates we have for the firmware-nonfree package.

You can find them here:
https://security-tracker.debian.org/tracker/source-package/firmware-nonfree

I can see that all the related CVEs are marked as no-dsa for buster, simply
because there is no security support for the non-free section. This rule
also applies to LTS but with the exception of the firmware-nonfree package.

My questions to you are the following:
1) Do you think any of the listed CVEs are important enough to warrant an
upload to buster and/or stretch?
2) Do you plan to do this for buster?
3) Would you mind if some LTS developer does such an upload for buster?

Having a later version in oldstable (compared to stable) is not a
good practice so if any of them are important we should update both
oldstable and stable.

Thank you in advance,

// Ola


-- 
 --- Inguza Technology AB --- MSc in Information Technology 
|  o...@inguza.como...@debian.org|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
 ---

Re: Best way forward for CVE-2021-22876/curl?

[Ola Lundqvist]

Hi again

I was able to reproduce the issue and I can confirm that it is  solved by
the update.

On an unfixed version I run the following:
   curl -L -e ";auto" -raw -v http://test:p...@inguza.com/'

And the resulting Referer output was:
> Referer: http://test:p...@inguza.com/

With the fixed package I run the same command:
 curl -L -e ";auto" -raw -v http://test:p...@inguza.com/'

And the resulting Referer output was correctly  stripped:
> Referer: http://inguza.com/

Great!

So I think it looks good.

Best regards

// Ola


On Mon, 17 May 2021 at 12:30, Ola Lundqvist  wrote:

> Hi Sylvain
>
> I have done some regression testing and it looks fine.
>
> I'll try to reproduce the actual issue too.
>
> // Ola
>
> On Mon, 17 May 2021 at 11:09, Sylvain Beucler  wrote:
>
>> Hi,
>>
>> I thought you'd rebuild but here you go.
>>
>> I intend to upload today.
>>
>> Cheers!
>> Sylvain
>>
>> On 17/05/2021 08:13, Ola Lundqvist wrote:
>> > Hi again Sylvain
>> >
>> > Today I was about to test the packages but I realize that I only have a
>> > libcurl-doc deb file to test.
>> >
>> > Will you upload the rest for testing too?
>> >
>> > // Ola
>> >
>> > On Sun, 16 May 2021 at 09:08, Ola Lundqvist > > > wrote:
>> >
>> > Hi
>> >
>> > I have reviewed the changes and it looks good.
>> > I'll see if I can get some time to perform any relevant tests too.
>> >
>> > // Ola
>> >
>> > On Sat, 15 May 2021 at 23:34, Sylvain Beucler > > > wrote:
>> >
>> > Hi Ola,
>> >
>> > You can check the LTS version at:
>> > https://www.beuc.net/tmp/debian-lts/curl/
>> > 
>> >
>> > I followed the method from Ubuntu and SUSE and backported the
>> > URL API
>> > for LTS and ELTS, plus the new test case for the CVE.
>> >
>> > I'm currently diffing the test suite results, cf. my notes at:
>> > https://wiki.debian.org/LTS/TestSuites/curl
>> > 
>> >
>> > Cheers!
>> > Sylvain
>> >
>> > On 15/05/2021 23:22, Ola Lundqvist wrote:
>> >  > Hi Sylvain
>> >  >
>> >  > Great! Let me know if you want help with review, testing or
>> > something else.
>> >  >
>> >  > // Ola
>> >  >
>> >  > On Sat, 15 May 2021 at 23:18, Sylvain Beucler > > 
>> >  > >> wrote:
>> >  >
>> >  > Hi,
>> >  >
>> >  > I claimed it yesterday and my work is mostly done.
>> >  >
>> >  > Cheers!
>> >  > Sylvain
>> >  >
>> >  > On 15/05/2021 23:11, Ola Lundqvist wrote:
>> >  >  > Hi Utkarsh
>> >  >  >
>> >  >  > I have looked into your patch and I think it looks
>> > good. I do not
>> >  > fully
>> >  >  > understand why all the changes in url.c were done but
>> > I think it
>> >  > looks
>> >  >  > fine anyway.
>> >  >  > The risk of regression should be small.
>> >  >  >
>> >  >  > Do you want me to do the update, or do you want to do
>> > it yourself?
>> >  >  > Or do you think we should ignore it?
>> >  >  >
>> >  >  > Best regards
>> >  >  >
>> >  >  > // Ola
>> >  >  >
>> >  >  > On Thu, 8 Apr 2021 at 22:33, Ola Lundqvist
>> > mailto:o...@inguza.com>
>> >  > >
>> >  >  > 
>> > > >  >  >
>> >  >  > Hi Utkarsh, all
>> >  >  >
>> >  >  > I have done some more investigation on this
>> > matter. I have
>> >  > checked
>> >  >  > the statement from upstream that we can re-use
>> > some existing
>> >  > strip
>> >  >  > code to remove the strings this way.
>> >  >  > The thing is that I cannot find any code that do
>> > URL stripping so
>> >  >  > that is not really a viable option. This leaves
>> > only the two
>> >  > options
>> >  >  > you have already stated.
>> >  >  >
>> >  >  > Either we ignore, or we port the entire URL API.
>> >  >  >
>> >  >  > I think the risk of regression is rather small if
>> > we port it,
>> >  >  > because this is only used in this place. Assuming
>> > there is no
>> >  > name
>> >  >  > clash introduced.
>> >  >  >
>> >  

Re: Best way forward for CVE-2021-22876/curl?

[Ola Lundqvist]

Hi Sylvain

I have done some regression testing and it looks fine.

I'll try to reproduce the actual issue too.

// Ola

On Mon, 17 May 2021 at 11:09, Sylvain Beucler  wrote:

> Hi,
>
> I thought you'd rebuild but here you go.
>
> I intend to upload today.
>
> Cheers!
> Sylvain
>
> On 17/05/2021 08:13, Ola Lundqvist wrote:
> > Hi again Sylvain
> >
> > Today I was about to test the packages but I realize that I only have a
> > libcurl-doc deb file to test.
> >
> > Will you upload the rest for testing too?
> >
> > // Ola
> >
> > On Sun, 16 May 2021 at 09:08, Ola Lundqvist  > > wrote:
> >
> > Hi
> >
> > I have reviewed the changes and it looks good.
> > I'll see if I can get some time to perform any relevant tests too.
> >
> > // Ola
> >
> > On Sat, 15 May 2021 at 23:34, Sylvain Beucler  > > wrote:
> >
> > Hi Ola,
> >
> > You can check the LTS version at:
> > https://www.beuc.net/tmp/debian-lts/curl/
> > 
> >
> > I followed the method from Ubuntu and SUSE and backported the
> > URL API
> > for LTS and ELTS, plus the new test case for the CVE.
> >
> > I'm currently diffing the test suite results, cf. my notes at:
> > https://wiki.debian.org/LTS/TestSuites/curl
> > 
> >
> > Cheers!
> > Sylvain
> >
> > On 15/05/2021 23:22, Ola Lundqvist wrote:
> >  > Hi Sylvain
> >  >
> >  > Great! Let me know if you want help with review, testing or
> > something else.
> >  >
> >  > // Ola
> >  >
> >  > On Sat, 15 May 2021 at 23:18, Sylvain Beucler  > 
> >  > >> wrote:
> >  >
> >  > Hi,
> >  >
> >  > I claimed it yesterday and my work is mostly done.
> >  >
> >  > Cheers!
> >  > Sylvain
> >  >
> >  > On 15/05/2021 23:11, Ola Lundqvist wrote:
> >  >  > Hi Utkarsh
> >  >  >
> >  >  > I have looked into your patch and I think it looks
> > good. I do not
> >  > fully
> >  >  > understand why all the changes in url.c were done but
> > I think it
> >  > looks
> >  >  > fine anyway.
> >  >  > The risk of regression should be small.
> >  >  >
> >  >  > Do you want me to do the update, or do you want to do
> > it yourself?
> >  >  > Or do you think we should ignore it?
> >  >  >
> >  >  > Best regards
> >  >  >
> >  >  > // Ola
> >  >  >
> >  >  > On Thu, 8 Apr 2021 at 22:33, Ola Lundqvist
> > mailto:o...@inguza.com>
> >  > >
> >  >  > 
> >  >  >  >
> >  >  > Hi Utkarsh, all
> >  >  >
> >  >  > I have done some more investigation on this
> > matter. I have
> >  > checked
> >  >  > the statement from upstream that we can re-use
> > some existing
> >  > strip
> >  >  > code to remove the strings this way.
> >  >  > The thing is that I cannot find any code that do
> > URL stripping so
> >  >  > that is not really a viable option. This leaves
> > only the two
> >  > options
> >  >  > you have already stated.
> >  >  >
> >  >  > Either we ignore, or we port the entire URL API.
> >  >  >
> >  >  > I think the risk of regression is rather small if
> > we port it,
> >  >  > because this is only used in this place. Assuming
> > there is no
> >  > name
> >  >  > clash introduced.
> >  >  >
> >  >  > So what do you all think? Ignore or fix?
> >  >  > There are good arguments for both.
> >  >  >
> >  >  > Ignore is ok because this only happens with a
> specific
> >  > command line
> >  >  > option, and even if used the risk of problem is
> > quite small.
> >  >  >
> >  >  > On the other hand curl is a very common tool which
> > means that it
> >  >  > could be worth fixing even small issues.
> >  >  >
> >  >  > I think both are ok.
> >  >  >
> >  >  > Best regards
> >  >  >
> >  >  > // 

Re: Upgrade problems from LTS -> LTS+1

[Ola Lundqvist]

Hi all

And this is the result:

Fist I instructed apt to download stretch and buster source packages files.

After that I run the command like this:
ola@tigereye:~$ ./checkversions.pl --old
/var/lib/apt/lists/httpredir.debian.org_debian_dists_stretch_main_source_Sources
--old-sec
/var/lib/apt/lists/httpredir.debian.org_debian-security_dists_stretch_updates_main_source_Sources
--new
/var/lib/apt/lists/httpredir.debian.org_debian_dists_buster_main_source_Sources
--new-sec
/var/lib/apt/lists/httpredir.debian.org_debian-security_dists_buster_updates_main_source_Sources

And the output is as follows:

mqtt-client: 1.14-1+deb9u1 newer than 1.14-1
ruby-websocket-extensions: 0.1.2-1+deb9u1 newer than 0.1.2-1
velocity: 1.7-5+deb9u1 newer than 1.7-5
debian-security-support: 1:9+2021.01.23 newer than 2020.06.21~deb10u1

So it looks like we have four packages to fix, that is four packages that
have a higher revision in stretch than in buster. I'm a little  surprised
about the debian-security-support package here.

Where do you think I should include this tool and what should I name it to?

Currently it just detects errors, it does not know whether the version
error is from normal release or security release. This could be added if
necessary.

Best regards

// Ola

On Mon, 17 May 2021 at 10:56, Ola Lundqvist  wrote:

> Hi
>
> Yes that makes sense. I can write some tool for that too. But now I'm
> focusing on finding already existing problems. The script is almost ready.
> I'm testing it right now.
>
> // Ola
>
> On Mon, 17 May 2021 at 10:49, Utkarsh Gupta  wrote:
>
>> Hello,
>>
>> On Mon, May 17, 2021 at 2:05 PM Ola Lundqvist  wrote:
>> > 3) Merge the normal release with the security release (takes the latest)
>>
>> Yeah, the goal is to cover all sorts of releases (normal, -pu, security)
>> and
>> get the highest version amongst them.
>>
>> > 4) Compare the two merged sets and check if the later release has any
>> > entry that is lower than the older release. Output those as "package
>> version".
>>
>> I think we shouldn't wait for when the package in the older release
>> has a greater version but check them *before*. That is, those packages
>> having the same version in ELTS & LTS or LTS & LTS+1 should be
>> flagged. This means, if they're added to {ela,dla}-needed, they should
>> either warrant a DSA upload or a -pu upload along with the DLA or ELA.
>> Hope that makes sense?
>>
>>
>>
>> - u
>>
>>
>
> --
>  --- Inguza Technology AB --- MSc in Information Technology 
> |  o...@inguza.como...@debian.org|
> |  http://inguza.com/Mobile: +46 (0)70-332 1551 |
>  ---
>
>

-- 
 --- Inguza Technology AB --- MSc in Information Technology 
|  o...@inguza.como...@debian.org|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
 ---

Re: Firmware-nonfree update for buster?

[Moritz Muehlenhoff]

On Mon, May 17, 2021 at 11:54:05AM +0200, Ola Lundqvist wrote:
> Hi firmware-nonfree maintainers
> 
> I have a question from an LTS perspective about the possible security
> updates we have for the firmware-nonfree package.
> 
> You can find them here:
> https://security-tracker.debian.org/tracker/source-package/firmware-nonfree

Did you even look at the CVEs in question? CVE-2020-1236[2,3,4] need
a kernel patch to actually allow to use the new firmware and that patch
isn't present in 4.19 (and ofc also not in 4.9)

Cheers,
Moritz

Re: Upgrade problems from LTS -> LTS+1

[Utkarsh Gupta]

Hello,

On Mon, May 17, 2021 at 3:08 PM Ola Lundqvist  wrote:
> mqtt-client: 1.14-1+deb9u1 newer than 1.14-1

Abhijith, can you please take care of this? You need a -pu update
prepared for this.

> ruby-websocket-extensions: 0.1.2-1+deb9u1 newer than 0.1.2-1

Already has an opened -pu bug.

> velocity: 1.7-5+deb9u1 newer than 1.7-5

Already has an opened -pu bug.

> debian-security-support: 1:9+2021.01.23 newer than 2020.06.21~deb10u1

Holger, can you TAL?

> Where do you think I should include this tool and what should I name it to?

Hm, nice question :P
Probably here: https://salsa.debian.org/freexian-team?

Naming is your choice :)

> Currently it just detects errors, it does not know whether the version error 
> is
> from normal release or security release. This could be added if necessary.

I think as long as it detects and reports the actual problem, that
won't be necessary. But obviously good to know that we can have it if
need be.

Thanks for working on this! :)


- u

Re: Golang packages

[Ola Lundqvist]

Hi

Ok, thanks for the clarification.

But we should then generally mark golang updates as no-dsa unless they are
critical, right?
For example golang-gogoprotobuf are rather questionable whether we should
fix at all.

// Ola

On Mon, 17 May 2021 at 11:44, Sylvain Beucler  wrote:

> Hi,
>
> According to debian-security-support, golang packages are not
> "unsupported" but with "limited support".
> Currently some packages are updated in stable and rdeps are manually
> bin-num'd (e.g. #946467), see also
> https://www.debian.org/News/2020/20200718 for stretch-before-LTS.
> It looks like golang will be fully supported in bullseye, so IMHO we'd
> rather prepare to handle some critical golang updates and not mass-EOL
> these packages.
>
> Cheers!
> Sylvain
>
> On 17/05/2021 09:20, Ola Lundqvist wrote:
> > Hi fellow LTS contributors
> >
> > I have a question about go package support.
> >
> > The question is whether we should try to support it in LTS or not:
> > According to this we do not give security support for go packages in
> > buster.
> >
> https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#golang-static-linking
> > <
> https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#golang-static-linking
> >
> >
> > There is also a discussion thread about adding this kind of information
> > to debian-security-support package, but there are concerns about
> > wildcards being a little too noisy.
> >
> > I can also see a note in dla-needed for Thorsten working on automating
> > go updates.
> >
> > My thinking is that we should remove these packages from dla-needed.txt
> > file and mark the CVE entries as EOL.
> >
> > Alternatively make some statement that we do in fact intend to make
> > these updates even though they are not done for buster. Buf in that
> > case, what is the motivation for making such updates for oldstable when
> > there is no plan to do is for stable.
> >
> > What do you think?
>


-- 
 --- Inguza Technology AB --- MSc in Information Technology 
|  o...@inguza.como...@debian.org|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
 ---

Re: Upgrade problems from LTS -> LTS+1

[Utkarsh Gupta]

Hello,

On Mon, May 17, 2021 at 5:06 PM Holger Levsen  wrote:
> > Holger, can you TAL?
> Gee...  I don't know what TAL means...

Heh. Take A Look (TAL) :)

> That said, I'm aware of this issue and have been waiting for an issue worth
> updating debian-security-support in buster. I don't think the version skew
> alone is worth an update, *maybe* as part of a point release it
> is.

Great, as long as you're aware of this issue, it's great! \o/


- u

Re: Golang packages

[Sylvain Beucler]

Hi,

According to debian-security-support, golang packages are not 
"unsupported" but with "limited support".
Currently some packages are updated in stable and rdeps are manually 
bin-num'd (e.g. #946467), see also 
https://www.debian.org/News/2020/20200718 for stretch-before-LTS.
It looks like golang will be fully supported in bullseye, so IMHO we'd 
rather prepare to handle some critical golang updates and not mass-EOL 
these packages.


Cheers!
Sylvain

On 17/05/2021 09:20, Ola Lundqvist wrote:

Hi fellow LTS contributors

I have a question about go package support.

The question is whether we should try to support it in LTS or not:
According to this we do not give security support for go packages in 
buster. 
https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#golang-static-linking 



There is also a discussion thread about adding this kind of information 
to debian-security-support package, but there are concerns about 
wildcards being a little too noisy.


I can also see a note in dla-needed for Thorsten working on automating 
go updates.


My thinking is that we should remove these packages from dla-needed.txt 
file and mark the CVE entries as EOL.


Alternatively make some statement that we do in fact intend to make 
these updates even though they are not done for buster. Buf in that 
case, what is the motivation for making such updates for oldstable when 
there is no plan to do is for stable.


What do you think?

Re: Golang packages

[Brian May]

Ola Lundqvist  writes:

> I can also see a note in dla-needed for Thorsten working on automating go
> updates.

I did a bit of work trying to automate go updates on my system:

* Identifying what packages need to be updated.
* Downloading said packages.
* Rebuilding.
* Uploading.

But there is still a lot of manual steps:

* Confirm that it is OK at add dependencies to dla-needed.txt
* Adding list of dependencies to dla-needed.txt, ensuring no conflicts.
* Reserve DLA for each package uploaded.
* Create DLA email for each package uploaded.
* Add DLA to website.
* Ping ftp-master when the upload fails.
* etc

And then what could happen (at least in theory) is that now I have
resolved this vulnerability, I start investigating another security
vulnerability that has a similar set of dependencies that require
rebuilding. Uploading these again is not a good outcome. It would be
better to fix all the root packages at once, and then upload the all the
dependencies.

Maybe we need a way of identifying all the dependencies at triage time,
and somehow(?) manage them better at triage time. Although my gut
feeling is we might be coming to the limits of what we can manage with a
simple text based dla-needed.txt file.

I am also a bit uneasy with the requirement for a separate DLA for each
and every package that needs to be uploaded. Could create a lot of
noise. Not sure I see any solutions though.

I think in the future (if we are not already there) we could easily have
a similar situation with rust - which I also believe likes to embed code
also.
-- 
Brian May