Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.security > #5657 > unrolled thread

Re: [Git][security-tracker-team/security-tracker][master] Add radare2 to dla-needed.txt with comments.

Back to article view | Back to linux.debian.security

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [Git][security-tracker-team/security-tracker][master] Add  radare2 to dla-needed.txt with comments. Holger Levsen <holger@layer-acht.org> - 2019-08-16 22:50 +0200
    Re: [Git][security-tracker-team/security-tracker][master] Add radare2  to dla-needed.txt with comments. Markus Koschany <apo@debian.org> - 2019-08-16 23:30 +0200
      Re: [Git][security-tracker-team/security-tracker][master] Add  radare2 to dla-needed.txt with comments. Moritz Mühlenhoff <jmm@inutil.org> - 2019-08-29 09:40 +0200
        Re: [Git][security-tracker-team/security-tracker][master] Add  radare2 to dla-needed.txt with comments. Raphael Hertzog <hertzog@debian.org> - 2019-08-29 13:50 +0200
          how to deal with widely used packages unsuitable for stable (was Re:  [Git][security-tracker-team/security-tracker][master] Add radare2 to  dla-needed.txt with comments.) Holger Levsen <holger@layer-acht.org> - 2019-08-29 14:20 +0200
            Re: how to deal with widely used packages unsuitable for stable (was  Re: [Git][security-tracker-team/security-tracker][master] Add radare2 to  dla-needed.txt with comments.) Raphael Hertzog <hertzog@debian.org> - 2019-08-29 14:30 +0200
              Re: how to deal with widely used packages unsuitable for stable (was  Re: [Git][security-tracker-team/security-tracker][master] Add radare2 to  dla-needed.txt with comments.) Paul Gevers <elbrus@debian.org> - 2019-08-29 15:20 +0200
                Re: how to deal with widely used packages unsuitable for stable (was  Re: [Git][security-tracker-team/security-tracker][master] Add radare2 to  dla-needed.txt with comments.) Dan Clery <dan@savevsgeek.com> - 2019-08-29 16:40 +0200
                  Re: how to deal with widely used packages unsuitable for stable (was  Re: [Git][security-tracker-team/security-tracker][master] Add radare2 to  dla-needed.txt with comments.) Raphael Hertzog <hertzog@debian.org> - 2019-08-30 09:20 +0200
                    Re: how to deal with widely used packages unsuitable for stable (was  Re: [Git][security-tracker-team/security-tracker][master] Add radare2 to  dla-needed.txt with comments.) Alexander Wirt <formorer@formorer.de> - 2019-08-30 09:40 +0200
                      Re: how to deal with widely used packages unsuitable for stable (was  Re: [Git][security-tracker-team/security-tracker][master] Add radare2 to  dla-needed.txt with comments.) Raphael Hertzog <hertzog@debian.org> - 2019-08-30 11:00 +0200
                        Re: how to deal with widely used packages unsuitable for stable (was  Re: [Git][security-tracker-team/security-tracker][master] Add radare2 to  dla-needed.txt with comments.) Alexander Wirt <formorer@formorer.de> - 2019-08-30 11:10 +0200
                          Re: how to deal with widely used packages unsuitable for stable (was  Re: [Git][security-tracker-team/security-tracker][master] Add radare2 to  dla-needed.txt with comments.) Raphael Hertzog <hertzog@debian.org> - 2019-08-30 16:50 +0200
                            Side issue/question -- {Re: how to deal with widely used packages  ...} Richard Owlett <rowlett@cloud85.net> - 2019-08-30 17:20 +0200
                            Re: how to deal with widely used packages unsuitable for stable (was  Re: [Git][security-tracker-team/security-tracker][master] Add radare2 to  dla-needed.txt with comments.) Alexander Wirt <formorer@formorer.de> - 2019-08-30 22:10 +0200
                    Re: how to deal with widely used packages unsuitable for stable (was  Re: [Git][security-tracker-team/security-tracker][master] Add radare2 to  dla-needed.txt with comments.) Moritz Mühlenhoff <jmm@inutil.org> - 2019-08-30 10:20 +0200
        Re: [Git][security-tracker-team/security-tracker][master] Add  radare2 to dla-needed.txt with comments. Moritz Mühlenhoff <jmm@inutil.org> - 2019-09-04 21:40 +0200

#5657 — Re: [Git][security-tracker-team/security-tracker][master] Add radare2 to dla-needed.txt with comments.

[Multipart message — attachments visible in raw view] — view raw

On Fri, Aug 16, 2019 at 08:11:58PM +0000, Markus Koschany wrote:
> Markus Koschany pushed to branch master at Debian Security Tracker / security-tracker
> 
> Commits:
> bc35662f by Markus Koschany at 2019-08-16T20:11:47Z
> Add radare2 to dla-needed.txt with comments.
> 
> - - - - -
> 1 changed file:
> - data/dla-needed.txt
> +radare2
> +  NOTE: 20190816: Affected by CVE-2019-14745. Vulnerable code is in
> +  NOTE: libr/core/bin.c. Many no-dsa issues in Jessie and Stretch. Should we
> +  NOTE: continue the current approach, update to a newer upstream version or mark
> +  NOTE: radare2 as unsupported? Also note that there is a r2-pwnDebian challenge...
> +  NOTE: https://bananamafia.dev/post/r2-pwndebian/ (apo)

I'd be in favor of marking radare2 as unsupported, probably even for stable,
but definitly for oldstable and older.

I'd be happy to do these changes in src:debian-security-tracker and
uploading this to sid.


-- 
cheers,
	Holger

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

[toc] | [next] | [standalone]

#5658 — Re: [Git][security-tracker-team/security-tracker][master] Add radare2 to dla-needed.txt with comments.

[Multipart message — attachments visible in raw view] — view raw

Hi,

Am 16.08.19 um 22:40 schrieb Holger Levsen:
> On Fri, Aug 16, 2019 at 08:11:58PM +0000, Markus Koschany wrote:
>> Markus Koschany pushed to branch master at Debian Security Tracker / security-tracker
>>
>> Commits:
>> bc35662f by Markus Koschany at 2019-08-16T20:11:47Z
>> Add radare2 to dla-needed.txt with comments.
>>
>> - - - - -
>> 1 changed file:
>> - data/dla-needed.txt
>> +radare2
>> +  NOTE: 20190816: Affected by CVE-2019-14745. Vulnerable code is in
>> +  NOTE: libr/core/bin.c. Many no-dsa issues in Jessie and Stretch. Should we
>> +  NOTE: continue the current approach, update to a newer upstream version or mark
>> +  NOTE: radare2 as unsupported? Also note that there is a r2-pwnDebian challenge...
>> +  NOTE: https://bananamafia.dev/post/r2-pwndebian/ (apo)
> 
> I'd be in favor of marking radare2 as unsupported, probably even for stable,
> but definitly for oldstable and older.
> 
> I'd be happy to do these changes in src:debian-security-tracker and
> uploading this to sid.

+1

I just noticed that we are not consistent with fixing CVE in radare2 and
I would also be in favor of marking it as unsupported. Another option
would be to package always the latest upstream release and backport that
to stable and oldstable but it seems we already lag behind a few
versions in unstable, so I'd rather choose the first option.

Markus

[toc] | [prev] | [next] | [standalone]

#5664

Adding the radare2 uploaders to CC.

On Fri, Aug 16, 2019 at 11:23:05PM +0200, Markus Koschany wrote:
> >> +  NOTE: 20190816: Affected by CVE-2019-14745. Vulnerable code is in
> >> +  NOTE: libr/core/bin.c. Many no-dsa issues in Jessie and Stretch. Should we
> >> +  NOTE: continue the current approach, update to a newer upstream version or mark
> >> +  NOTE: radare2 as unsupported? Also note that there is a r2-pwnDebian challenge...
> >> +  NOTE: https://bananamafia.dev/post/r2-pwndebian/ (apo)
> > 
> > I'd be in favor of marking radare2 as unsupported, probably even for stable,
> > but definitly for oldstable and older.
> > 
> > I'd be happy to do these changes in src:debian-security-tracker and
> > uploading this to sid.
> 
> +1
> 
> I just noticed that we are not consistent with fixing CVE in radare2 and
> I would also be in favor of marking it as unsupported. Another option
> would be to package always the latest upstream release and backport that
> to stable and oldstable but it seems we already lag behind a few
> versions in unstable, so I'd rather choose the first option.

The upstream link makes it sound as if they are one of those upstreams
which reject the idea of distributions shipping an older release to
a stable distro. For a tool like radare2 that seems fair enough, so
how about simply excluding it from stable releases (and retroactively
drop it from Buster/Stretch in the forthcoming point releases)?

Cheers,
         Moritz

[toc] | [prev] | [next] | [standalone]

#5665

Hi,

On Thu, 29 Aug 2019, Moritz Mühlenhoff wrote:
> The upstream link makes it sound as if they are one of those upstreams
> which reject the idea of distributions shipping an older release to
> a stable distro. For a tool like radare2 that seems fair enough, so
> how about simply excluding it from stable releases (and retroactively
> drop it from Buster/Stretch in the forthcoming point releases)?

<pkg-security hat>
While I have no problem in getting it out of stable release, it is
important that we are able to provide backports so the package must
stay in Debian testing. 
</pkg-security hat>

<kali hat>
Also radare2 is a package that we care about in Kali and we are based
on Debian testing so we would prefer if it could continue to be there.
</kali hat>

In general, we (Debian) don't have a good answer to this problem and
virtualbox is clearly a bad precedent. We really need to find a solution
to this in concertation with the release managers.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

[toc] | [prev] | [next] | [standalone]

#5666 — how to deal with widely used packages unsuitable for stable (was Re: [Git][security-tracker-team/security-tracker][master] Add radare2 to dla-needed.txt with comments.)

[Multipart message — attachments visible in raw view] — view raw

hi,

(this started as a discussion whether to update radare2 in (old)stable
and has since then evolved into a discussion about the problem
summarized well by Raphael.)

On Thu, Aug 29, 2019 at 01:48:14PM +0200, Raphael Hertzog wrote:
> On Thu, 29 Aug 2019, Moritz Mühlenhoff wrote:
> > The upstream link makes it sound as if they are one of those upstreams
> > which reject the idea of distributions shipping an older release to
> > a stable distro. For a tool like radare2 that seems fair enough, so
> > how about simply excluding it from stable releases (and retroactively
> > drop it from Buster/Stretch in the forthcoming point releases)?
> 
> <pkg-security hat>
> While I have no problem in getting it out of stable release, it is
> important that we are able to provide backports so the package must
> stay in Debian testing. 
> </pkg-security hat>
> 
> <kali hat>
> Also radare2 is a package that we care about in Kali and we are based
> on Debian testing so we would prefer if it could continue to be there.
> </kali hat>
> 
> In general, we (Debian) don't have a good answer to this problem and
> virtualbox is clearly a bad precedent. We really need to find a solution
> to this in concertation with the release managers.

so I've added them to this thread.

youtube-dl is in the same boat...


-- 
cheers,
	Holger

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

[toc] | [prev] | [next] | [standalone]

#5667 — Re: how to deal with widely used packages unsuitable for stable (was Re: [Git][security-tracker-team/security-tracker][master] Add radare2 to dla-needed.txt with comments.)

[Multipart message — attachments visible in raw view] — view raw

(Note: pkg-security@tracker.d.o is not a valid email, dropped)

Hi,

On Thu, 29 Aug 2019, Holger Levsen wrote:
> > In general, we (Debian) don't have a good answer to this problem and
> > virtualbox is clearly a bad precedent. We really need to find a solution
> > to this in concertation with the release managers.
> 
> so I've added them to this thread.
> 
> youtube-dl is in the same boat...

To kickstart the discussion, I can try to make a proposal.

1/ We tag such packages in some way (let's say a new field
  "Backport-Only: yes")

2/ Those packages are considered like others for testing migration
   but when britney accepts them, instead of adding them to "<testing-codename>"
   it adds them to "<testing-codename>-backports". Obviously this requires
   britney to consider the combination of both repositories when
   considering migrations. And it will require changes to generate two
   separate output files for dak.

   The hardest part is ensuring that testing doesn't contain packages that
   would depend on packages present only in the backports part. Not sure
   we want to handle this directly within britney. It might be better to
   have QA tools for this and report bugs as appropriate.

The good thing is that those applications are then available from day 1 in
stable-backports after the release.

The backports rules would have to be tweaked a bit to accept backports
coming out of "<testing>-backports". But all those aspects are a
relatively minor detail IMO.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

[toc] | [prev] | [next] | [standalone]

#5668 — Re: how to deal with widely used packages unsuitable for stable (was Re: [Git][security-tracker-team/security-tracker][master] Add radare2 to dla-needed.txt with comments.)

[Multipart message — attachments visible in raw view] — view raw

Hi

On 29-08-2019 14:28, Raphael Hertzog wrote:
> (Note: pkg-security@tracker.d.o is not a valid email, dropped)
> 
> Hi,
> 
> On Thu, 29 Aug 2019, Holger Levsen wrote:
>>> In general, we (Debian) don't have a good answer to this problem and
>>> virtualbox is clearly a bad precedent. We really need to find a solution
>>> to this in concertation with the release managers.
>>
>> so I've added them to this thread.
>>
>> youtube-dl is in the same boat...

Wasn't Pirate already working on a solution? How is that faring? I know
it doesn't have all the properties you are seeking, but ...

> To kickstart the discussion, I can try to make a proposal.
> 
> 1/ We tag such packages in some way (let's say a new field
>   "Backport-Only: yes")
> 
> 2/ Those packages are considered like others for testing migration
>    but when britney accepts them, instead of adding them to "<testing-codename>"
>    it adds them to "<testing-codename>-backports". Obviously this requires
>    britney to consider the combination of both repositories when
>    considering migrations. And it will require changes to generate two
>    separate output files for dak.
> 
>    The hardest part is ensuring that testing doesn't contain packages that
>    would depend on packages present only in the backports part. Not sure
>    we want to handle this directly within britney. It might be better to
>    have QA tools for this and report bugs as appropriate.
> 
> The good thing is that those applications are then available from day 1 in
> stable-backports after the release.
> 
> The backports rules would have to be tweaked a bit to accept backports
> coming out of "<testing>-backports". But all those aspects are a
> relatively minor detail IMO.

in the discussion that Pirate had with the backports masters, it was my
interpretation that they didn't like it.

Paul

[toc] | [prev] | [next] | [standalone]

#5669 — Re: how to deal with widely used packages unsuitable for stable (was Re: [Git][security-tracker-team/security-tracker][master] Add radare2 to dla-needed.txt with comments.)

[Multipart message — attachments visible in raw view] — view raw

Isn't this the sort of problem that things like flatpack or snap were
created for?

On Thu, Aug 29, 2019 at 9:57 AM Abhijith PA <abhijith@disroot.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
>
> Hi,
>
> On 29/08/19 6:47 pm, Paul Gevers wrote:
> > Hi
> >
> > On 29-08-2019 14:28, Raphael Hertzog wrote:
> >> (Note: pkg-security@tracker.d.o is not a valid email, dropped)
> >>
> >> Hi,
> >>
> >> On Thu, 29 Aug 2019, Holger Levsen wrote:
> >>>> In general, we (Debian) don't have a good answer to this
> >>>> problem and virtualbox is clearly a bad precedent. We really
> >>>> need to find a solution to this in concertation with the
> >>>> release managers.
> >>> so I've added them to this thread.
> >>>
> >>> youtube-dl is in the same boat...
> > Wasn't Pirate already working on a solution? How is that faring? I
> > know it doesn't have all the properties you are seeking, but ...
> >
>
> Yes, the http://fasttrack.debian.net/ is started for handling similar
> issue. Last time I checked the work is almost done and will be
> deployed soon.
>
>
> - --abhijith
> -----BEGIN PGP SIGNATURE-----
>
> iQIzBAEBCgAdFiEE7xPqJqaY/zX9fJAuhj1N8u2cKO8FAl1n1cwACgkQhj1N8u2c
> KO8TsQ//dy0Xff6X1422Ypr2HQHAVu/3rf4VXBQI8a5yo/nWVhvlvbrU65pyyRND
> tS3fDpc3m/nRJ82vAhXCxzU0mW7zIRiq3lyBc7V11BC81Fn50b4C8mDBj+XasY6/
> PXgCoW1B8b+7LoD9M85RWHV25OLEar9bNFbQTi7YrINxyWNIK4J5fZoRk5zD+wLs
> KShKCl4NGYNUYiwc9O5w8fDuA5Ty9Fgxop8xB0rk6kzWlRLIhnMC84aEwWs5EUq1
> lXcr7ONa5M9GnzIF2WsAfbHQVqplL5yMPVNlj4mkEtADb/gm0JWIC2Ye92UHdAL3
> BDV8gJjRs6DBg3vGMXXLkwzO8twe5zezoglrTC0MMNi+SnahTti7WU6yTzpomGqS
> vzx8haRtST2kC3xLg9y4P6dQC7dQGpzvmNDCPhpXADsb9C+9x6oGC3AqsTKOKkSS
> PtH0/7ME9QjlUFSIgA7no5hc74AR0wYTyi4qaF4Uv0zOJilbPaF4ExCcT2W3P85P
> 5LOp+tHqu1H08vxt7WprNnFWTkBRwyXYn3L5eH4aIjWy+WQg3hSkKaBMB4xDDpao
> of5vyTkyFhR36gBd82DzB7TJgw3gfuS/mCoG8QAmsm5pqwKVoDwacuPV9RXrKC5b
> CwRAvmwfN51S5LH6iKnlaSbcypNEkhRmngJqfkR5WHIA2SVeiJs=
> =jWMw
> -----END PGP SIGNATURE-----
>
>

[toc] | [prev] | [next] | [standalone]

#5670 — Re: how to deal with widely used packages unsuitable for stable (was Re: [Git][security-tracker-team/security-tracker][master] Add radare2 to dla-needed.txt with comments.)

Hi,

On Fri, 30 Aug 2019, Pirate Praveen wrote:
> Fast Track repo works exactly like current backports except the packages
> are added from unstable (or experimental during transitions and freeze)
> as they cannot go to testing and hence to current backports.
> 
> As Paul noted earlier, backports team is not interested to change
> current backports criteria.

Can you point us the discussion where this got refused?

Honestly I don't like the idea of using an external service. I would like
my unstable package to migrate automatically to this new testing sibling
repository and I would like britney to control this move to ensure
consistency.

So if <testing-codename>-backports (unused at the time where this would be useful
for this service!) can't be used we could find another name... but for
me it's important that it's on the main mirror and that it's controlled
by the same britney instance to ensure consistency with the main
repository.

Ideally it would be managed by the release team as a by-product of their
work on preparing the next stable release.

Or maybe we can switch the logic around. britney generates a new "rolling"
suite which includes all packages and afterwards we generate "testing" as
a subset of rolling by excluding the packages which are not supported in
stable and all their reverse dependencies. That would be even better in my
opinion.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

[toc] | [prev] | [next] | [standalone]

#5671 — Re: how to deal with widely used packages unsuitable for stable (was Re: [Git][security-tracker-team/security-tracker][master] Add radare2 to dla-needed.txt with comments.)

[Multipart message — attachments visible in raw view] — view raw

On Fri, 30 Aug 2019, Raphael Hertzog wrote:

> Hi,
> 
> On Fri, 30 Aug 2019, Pirate Praveen wrote:
> > Fast Track repo works exactly like current backports except the packages
> > are added from unstable (or experimental during transitions and freeze)
> > as they cannot go to testing and hence to current backports.
> > 
> > As Paul noted earlier, backports team is not interested to change
> > current backports criteria.
> 
> Can you point us the discussion where this got refused?
There were several discussions over the last years. And yes, our vision of
backports does not match the vision of those fastpace/not ready for
stable/whatever you call them repos. In our vision debian-backports consists
of new (tested, as in "is in testing") features from the next debian release.
By definition that does not match packages that will not be part of the next
debian release. 

Alex 

[toc] | [prev] | [next] | [standalone]

#5673 — Re: how to deal with widely used packages unsuitable for stable (was Re: [Git][security-tracker-team/security-tracker][master] Add radare2 to dla-needed.txt with comments.)

[Multipart message — attachments visible in raw view] — view raw

On Fri, 30 Aug 2019, Alexander Wirt wrote:
> There were several discussions over the last years. And yes, our vision of
> backports does not match the vision of those fastpace/not ready for
> stable/whatever you call them repos. In our vision debian-backports consists
> of new (tested, as in "is in testing") features from the next debian release.

"Tested as in testing" really means "tested by britney using the same
criteria as other packages" and in my earlier suggestion, I was precisely
saying that I do want to keep britney's filter between unstable
and <testing-codename>-backports (i.e. the unused bullseye-backports
during the bullseye development cycle).

Why would it be wrong to have virtualbox or mysql or wordpress or radare2
in the -backports repo?

We're not speaking of crap software, we're just speaking of software that
can't be maintained multiple years by backports of security patches, where
we get fixes only with new upstream versions (mixed with new features).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

[toc] | [prev] | [next] | [standalone]

#5674 — Re: how to deal with widely used packages unsuitable for stable (was Re: [Git][security-tracker-team/security-tracker][master] Add radare2 to dla-needed.txt with comments.)

[Multipart message — attachments visible in raw view] — view raw

On Fri, 30 Aug 2019, Raphael Hertzog wrote:

> On Fri, 30 Aug 2019, Alexander Wirt wrote:
> > There were several discussions over the last years. And yes, our vision of
> > backports does not match the vision of those fastpace/not ready for
> > stable/whatever you call them repos. In our vision debian-backports consists
> > of new (tested, as in "is in testing") features from the next debian release.
> 
> "Tested as in testing" really means "tested by britney using the same
> criteria as other packages" and in my earlier suggestion, I was precisely
> saying that I do want to keep britney's filter between unstable
> and <testing-codename>-backports (i.e. the unused bullseye-backports
> during the bullseye development cycle).
> 
> Why would it be wrong to have virtualbox or mysql or wordpress or radare2
> in the -backports repo?
> 
> We're not speaking of crap software, we're just speaking of software that
> can't be maintained multiple years by backports of security patches, where
> we get fixes only with new upstream versions (mixed with new features).
I don't want to draw that line, someone would have decide if the software is
just crap, the maintainer too lazy or if its really fast pacing. Wordpress is
an example of a software that should really be supported within stable. If
not its just crap. 

Imho we should have packages in testing that will not be part of the next
release. And we don't want any form of automated migrations. Full stop.
People should build and *test* their packages against stable. 

Alex

[toc] | [prev] | [next] | [standalone]

#5675 — Re: how to deal with widely used packages unsuitable for stable (was Re: [Git][security-tracker-team/security-tracker][master] Add radare2 to dla-needed.txt with comments.)

[Multipart message — attachments visible in raw view] — view raw

Hi,

On Fri, 30 Aug 2019, Alexander Wirt wrote:
> > We're not speaking of crap software, we're just speaking of software that
> > can't be maintained multiple years by backports of security patches, where
> > we get fixes only with new upstream versions (mixed with new features).
> I don't want to draw that line, someone would have decide if the software is
> just crap, the maintainer too lazy or if its really fast pacing. Wordpress is
> an example of a software that should really be supported within stable. If
> not its just crap. 
> 
> Imho we should have packages in testing that will not be part of the next
> release. And we don't want any form of automated migrations. Full stop.
> People should build and *test* their packages against stable. 

I don't know if I'm expressing myself very badly, but there's clearly a
misunderstanding.

Right now there is no "stable" release where you would build packages for
bullseye-backports. If you keep the same logic of building next release
packages against the current release, then for bullseye-backports that
would mean building packages from unstable in a testing environment.

There's usually no point in doing that because both distributions are very
close. The way to go from one one to the next is to go through britney.

To me it made sense because the split between testing and bullseye-backports
would follow the same logic as the split between stable and stable-backports:
in the former repositories you have versions of packages that can be
maintained over a long time, in the latter you have either versions of
such packages that can't be supported over multiple years or packages
for which there are no single version that can be supported multiple
years (e.g. because they are too complex and upstream supports only the latest
release).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

[toc] | [prev] | [next] | [standalone]

#5676 — Side issue/question -- {Re: how to deal with widely used packages ...}

I've causally/intermittently followed this thread.
There appears to be a problem of definitions and applicability.

Is there a page of definitions for jessie, jessie-updates, stretch, 
stretch-updates, stretch-backports, stretch-backports-sloppy, buster, 
buster-updates, buster-backports, bullseye, sid, experimental, 
"fastpace/not ready", "Fast Track repo", etc.

I use only "stable" so doesn't seem to affect me.

[toc] | [prev] | [next] | [standalone]

#5677 — Re: how to deal with widely used packages unsuitable for stable (was Re: [Git][security-tracker-team/security-tracker][master] Add radare2 to dla-needed.txt with comments.)

[Multipart message — attachments visible in raw view] — view raw

On Fri, 30 Aug 2019, Raphael Hertzog wrote:

> Hi,
> 
> On Fri, 30 Aug 2019, Alexander Wirt wrote:
> > > We're not speaking of crap software, we're just speaking of software that
> > > can't be maintained multiple years by backports of security patches, where
> > > we get fixes only with new upstream versions (mixed with new features).
> > I don't want to draw that line, someone would have decide if the software is
> > just crap, the maintainer too lazy or if its really fast pacing. Wordpress is
> > an example of a software that should really be supported within stable. If
> > not its just crap. 
> > 
> > Imho we should have packages in testing that will not be part of the next
> > release. And we don't want any form of automated migrations. Full stop.
> > People should build and *test* their packages against stable. 
> 
> I don't know if I'm expressing myself very badly, but there's clearly a
> misunderstanding.
> 
> Right now there is no "stable" release where you would build packages for
> bullseye-backports. If you keep the same logic of building next release
> packages against the current release, then for bullseye-backports that
> would mean building packages from unstable in a testing environment.
I have a problem with your definition(s). There is no bullseye-backports yet
and it will only be available short before its release. Backports is meaned
to support a stable release. 

Alex

[toc] | [prev] | [next] | [standalone]

#5672 — Re: how to deal with widely used packages unsuitable for stable (was Re: [Git][security-tracker-team/security-tracker][master] Add radare2 to dla-needed.txt with comments.)

On Fri, Aug 30, 2019 at 09:17:32AM +0200, Raphael Hertzog wrote:
> Hi,
> 
> On Fri, 30 Aug 2019, Pirate Praveen wrote:
> > Fast Track repo works exactly like current backports except the packages
> > are added from unstable (or experimental during transitions and freeze)
> > as they cannot go to testing and hence to current backports.
> > 
> > As Paul noted earlier, backports team is not interested to change
> > current backports criteria.
> 
> Can you point us the discussion where this got refused?
> 
> Honestly I don't like the idea of using an external service.

Let's just see how it works out? backports also started as an external service
and was eventually moved under debian.org infrastructure.

Cheers,
        Moritz

[toc] | [prev] | [next] | [standalone]

#5678

On Thu, Aug 29, 2019 at 09:36:39AM +0200, Moritz Mühlenhoff wrote:
> Adding the radare2 uploaders to CC.
> 
> On Fri, Aug 16, 2019 at 11:23:05PM +0200, Markus Koschany wrote:
> > >> +  NOTE: 20190816: Affected by CVE-2019-14745. Vulnerable code is in
> > >> +  NOTE: libr/core/bin.c. Many no-dsa issues in Jessie and Stretch. Should we
> > >> +  NOTE: continue the current approach, update to a newer upstream version or mark
> > >> +  NOTE: radare2 as unsupported? Also note that there is a r2-pwnDebian challenge...
> > >> +  NOTE: https://bananamafia.dev/post/r2-pwndebian/ (apo)
> > > 
> > > I'd be in favor of marking radare2 as unsupported, probably even for stable,
> > > but definitly for oldstable and older.
> > > 
> > > I'd be happy to do these changes in src:debian-security-tracker and
> > > uploading this to sid.
> > 
> > +1
> > 
> > I just noticed that we are not consistent with fixing CVE in radare2 and
> > I would also be in favor of marking it as unsupported. Another option
> > would be to package always the latest upstream release and backport that
> > to stable and oldstable but it seems we already lag behind a few
> > versions in unstable, so I'd rather choose the first option.
> 
> The upstream link makes it sound as if they are one of those upstreams
> which reject the idea of distributions shipping an older release to
> a stable distro. For a tool like radare2 that seems fair enough, so
> how about simply excluding it from stable releases (and retroactively
> drop it from Buster/Stretch in the forthcoming point releases)?

Hilko/Sebastian,
as the last uploaders; what do you think? How should we proceed wrt radare in oldstable/stable?

Cheers,
         Moritz

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.security

csiph-web