Re: Backports needed for Firefox/Thunderbird ESR 78 in Buster/Stretch

2020-08-02 Thread Carsten Schoenert

Hi Emilio,

Am 28.07.20 um 22:17 schrieb Emilio Pozuelo Monfort:

Any help in updating these would be welcome.


the rust and clang universe isn't something I'm really familiar with. 
And diving into this isn't possible due the usual time constrains, too 
much other things I'm currently doing.


So from my side I can't provide much help on updating the required 
packages. I'm happy to adopt the new Thunderbird ESR series to buster 
and maybe stretch.


--
Regards
Carsten



Re: Backports needed for Firefox/Thunderbird ESR 78 in Buster/Stretch

2020-08-02 Thread Moritz Mühlenhoff
On Tue, Jul 28, 2020 at 10:17:35PM +0200, Emilio Pozuelo Monfort wrote:
> Hi,
> 
> On 21/08/2019 07:45, Salvatore Bonaccorso wrote:
> > Hi Holger, hi Emilio,
> > 
> > [dropping debian-devel list]
> > 
> > On Mon, Aug 19, 2019 at 11:01:13PM +0200, Moritz Mühlenhoff wrote:
> >> On Tue, Jul 02, 2019 at 10:45:20PM +0200, Moritz Mühlenhoff wrote:
> >>> Hi,
> >>> Firefox 68 will be the next ESR release series. With the release of 
> >>> Firefox 68.2
> >>> on October 22nd, support for ESR 60 will cease.
> >>>
> >>> ESR 68 will require an updated Rust/Cargo toolchain and build 
> >>> dependencies not
> >>> present in Stretch (nodejs 8, llvm-toolchain-7, cbindgen and maybe more).
> >>> Stretch was already updated wrt Rust/Cargo for ESR 60, so there's at 
> >>> least no
> >>> requirement to bootstrap stage0 builds this time.
> >>>
> >>> If we want to continue to have Firefox/Thunderbird supported in 
> >>> oldstable-security
> >>> after October, someone needs to step up to take care of backports to a 
> >>> Stretch point
> >>> release before October 22nd (or in case of poor timing, we can also 
> >>> release build
> >>> dependency updates via stretch-security).
> >>
> >> There hasn't been any visible movement on this, so unless someone steps up 
> >> RSN,
> >> there'll be a headsup about the EOL in the next ESR 60 DSA, so that people
> >> have some advance warning.
> > 
> > That would be really bad I guess both for users running stretch on
> > workstations for a while (we are affected for instance at work) and
> > for LTS as there were work so far by emilio to keep up firefox-esr and
> > thunderbird as well updated in jessie LTS.
> 
> We are at this point again. ESR 68 will be EOL on September 22nd, when 78.3
> comes out. We have some time still, but if we want FF and TB to keep being
> supported, we'll have to do some toolchain backports as usual.
> 
> Has someone started to look at this?
> 
> I have taken a quick look and it looks like we need rustc 1.41 and cargo 0.31.
> We currently have:
> 
> rustc  | 1.34.2+dfsg1-1~deb9u1 | oldstable
> rustc  | 1.34.2+dfsg1-1| stable
> rustc  | 1.44.1+dfsg1-1| unstable
> 
> cargo  | 0.35.0-2~deb9u2 | oldstable
> cargo  | 0.35.0-2| stable
> cargo  | 0.43.1-3| unstable
> 
> We may need other deps after those (such as an updated cbindgen or other
> modules) or some packages in order to build those (possibly LLVM 9, I'm not 
> sure
> yet).

I don't have time to work on this, I'm away for large parts of August,
but I had a look at what is needed:

We'll need LLVM 9 (which was a straight rebuild on buster in my test),
wasi-libc (also a straight rebuild with LLVM 9) and updated rustc. Updating
rustc will require some intermediate rustc/cargo uploads as we can't build
1.41 with 1.34.

We can also avoid these in the future by always bumping rustc to the
current version in point releases...

I think we can reuse the same approach as before, by staging uploads
in -proposed-updates (or on stretch-security respectively) and then
configure the security chroots to use -proposed-updates until 10.6
is eventually released.

Cheers,
Moritz



LTS report for July 2020

2020-08-02 Thread Adrian Bunk
Hours worked:
16 hours

DLAs released:
DLA-2291 ffmpeg CVE-2019-13390 CVE-2019-17542 CVE-2020-13904
DLA-2292 milkytracker CVE-2019-14464 CVE-2019-14496 CVE-2019-14497 
  CVE-2020-15569
DLA-2302 libjpeg-turbo CVE-2018-1152 CVE-2018-14498 CVE-2020-13790 
   CVE-2020-14152



Making stretch-security build logs public

2020-08-02 Thread Emilio Pozuelo Monfort
Hi,

I was wondering if we could make old stretch-security build logs public. I
suppose there's nothing private there anymore (no more embargoed updates in
stretch) and it can help in debugging issues with updates (e.g. I just uploaded
a new thunderbird version there and I've noticed that the previous versions
failed to build on arm{hf,64} and I wanted to refresh my memory on why.

Thanks,
Emilio



Re: Making stretch-security build logs public

2020-08-02 Thread Salvatore Bonaccorso
Hi Emilio,

On Sun, Aug 02, 2020 at 11:54:27PM +0200, Emilio Pozuelo Monfort wrote:
> I was wondering if we could make old stretch-security build logs public. I
> suppose there's nothing private there anymore (no more embargoed updates in
> stretch) and it can help in debugging issues with updates (e.g. I just 
> uploaded
> a new thunderbird version there and I've noticed that the previous versions
> failed to build on arm{hf,64} and I wanted to refresh my memory on why.

In case this is easily implementable for the old logs then I guess
this is fine from security team perspective.

Regards,
Salvatore