Re: Closing of buster-backports?
Am Wed, Sep 07, 2022 at 10:11:15PM +0200 schrieb Rene Engelhard: > Hi, > > whatever is fine, I can live with both, but: > > Am 07.09.22 um 07:37 schrieb Alexander Wirt: > > > > Now that buster is LTS and no longer officially supported, should the > > > > -backports pocket be closed? AFAIK, buster just receives the security > > > > uploads by the -security pocket and shouldn't have -backports open > > > > anymore. I hope I am not mistaken or missing anything? > > > > > > > > FTR, packages are still entering the -backports pocket and this > > > > probably needs to stop(!?) > > > Why should it stop? If people are willing to do the work to backport a > > > package, why should it be blocked? The understanding is that the release > > > as > > > a whole will not be supported, but voluntary updates will continue. > > we (backports ftpmasters) asked that question some time ago. Consensus was > > that the backports > > maintainers doesn't want to support oldstable backports over its lts > > lifetime. > > I would maintain them (by backporting what is in bullseye. > > What I surely will not do is to do updates in buster itself, so any security > update in buster will probably only be over this way. (Or none, unless the > LTS team actually backports the patches, which can be cumbersome even for > 7.0.4. Now think of a 6.1.5 :)) > > > For that reason we will close oldstable-backports soon. > > What is "soon"? > > I have already libreoffice 1:7.0.4-4+deb11u3~bpo10+1 in deferred (should > become real on Saturday after the point release adding that > 1:7.0.4-4+deb11u3 to stable) Now that Buster is in LTS mode I would expect that to happen within the next weeks. Alex signature.asc Description: PGP signature
Re: Closing of buster-backports?
Am Wed, Sep 07, 2022 at 08:25:36AM +0200 schrieb Kees Meijs | Nefos: > Morning, > > Will it still be available through some FTP archive? (Although, being > static.) For some time it will last on the official mirrors, we will move it to archive.debian.org at a later point. Alex
Re: Closing of buster-backports?
Hi, > > Now that buster is LTS and no longer officially supported, should the > > -backports pocket be closed? AFAIK, buster just receives the security > > uploads by the -security pocket and shouldn't have -backports open > > anymore. I hope I am not mistaken or missing anything? > > > > FTR, packages are still entering the -backports pocket and this > > probably needs to stop(!?) > > Why should it stop? If people are willing to do the work to backport a > package, why should it be blocked? The understanding is that the release as > a whole will not be supported, but voluntary updates will continue. we (backports ftpmasters) asked that question some time ago. Consensus was that the backports maintainers doesn't want to support oldstable backports over its lts lifetime. For that reason we will close oldstable-backports soon. Alex
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, 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 signature.asc Description: PGP signature
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, 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 -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 signature.asc Description: PGP signature
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, 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 signature.asc Description: PGP signature
Re: jessie-updates gone
On Tue, 26 Mar 2019, Jakob Hirsch wrote: > Hi, > > so I noticed this morning that jessie-updates is gone from the mirrors. > After some research, I found that this was kind of announced in > https://lists.debian.org/debian-devel-announce/2019/03/msg6.html. > Question is now, what should I put in my sources.list? I used > https://wiki.debian.org/LTS/Using#Using_Debian_Long_Term_Support_.28LTS.29 > as the authorative source, but this is obviously outdated now. > > So, am I ok by just using these two? Its deprecated and unsupported for sime time now, please stop using it. Alex
Re: Newer kernel for jessie backports
On Thu, 14 Mar 2019, Moritz Mühlenhoff wrote: > On Thu, Mar 14, 2019 at 01:57:37PM +0100, Alexander Wirt wrote: > > On Thu, 14 Mar 2019, Arthur de Jong wrote: > > > > > -BEGIN PGP SIGNED MESSAGE- > > > Hash: SHA256 > > > > > > > > > Hi, > > > > > > In jessie backports there is currently a 4.9 kernel > > > (4.9.110-3+debu5~deb8u1) > > > which is based on stretch 4.9.110-3+deb9u2. Since stretch now has > > > 4.9.144-3.1 are there any plans to make a 4.9.144-3.1~deb8u1 for jessie? > > > > > > I have a piece of hardware that requires the newer kernel but will sadly > > > not > > > be able to upgrade to stretch for a few months. > > > > > > Is there something I can do to help this along? > > jessie-backports is unsupprted for some time now. > > The 4.9 kernel in jessie LTS is unrelated to jessie-backports, it's a separate > source package which continues support for 4.9.x users in jessie-security: > https://packages.qa.debian.org/l/linux-4.9.html Ah you are right, I was fooled by the mentioning of backports. Please ignore me :). Alex
Re: Newer kernel for jessie backports
On Thu, 14 Mar 2019, Arthur de Jong wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > > Hi, > > In jessie backports there is currently a 4.9 kernel (4.9.110-3+debu5~deb8u1) > which is based on stretch 4.9.110-3+deb9u2. Since stretch now has > 4.9.144-3.1 are there any plans to make a 4.9.144-3.1~deb8u1 for jessie? > > I have a piece of hardware that requires the newer kernel but will sadly not > be able to upgrade to stretch for a few months. > > Is there something I can do to help this along? jessie-backports is unsupprted for some time now. Alex
Re: Bug#921663: Please add python-certbot update to jessie-backports
On Mon, 11 Feb 2019, Brad Warren wrote: > I agree with the concerns about updating python3-cryptography in jessie. > > If we can’t update jessie, I’d ideally love to see the packages in > jessie-backports updated. Despite the announcement that jessie-backports was > discontinued ~6 months ago, tens of thousands of users and many more domains > continue to rely on these packages as I wrote earlier in this thread. It > would be great if a simple package upgrade was all they needed to do to > prevent their TLS configurations from breaking. Its closed, we won't change it anymore and it will be (hopefully) archived soon, then its even not available on the mirrors anymore. Alex - backports ftpmaster
Re: Backports LTS security support
On Fri, 08 Feb 2019, Paul van der Vlis wrote: > Op 08-02-19 om 15:29 schreef Alexander Wirt: > > On Fri, 08 Feb 2019, Paul van der Vlis wrote: > > > >> Hello, > >> > >> I would like to have LTS support for backports. On most systems I use > >> one or more packages from backports. > >> > >> When the same version of a package is in use in the next version of > >> Debian, I guess backporting them is -in most cases- not a big problem. > >> > >> I am interesting if it would be a good idea to ask maintainers in the > >> freeze-phase to put the same versions in stable-backports, if the > >> package is in backports. > >> > >> Maybe we could say somewhere in the future: LTS supports backports, but > >> only when the same version of a package is in the next Debian version. > >> With some exceptions. > >> > >> Maybe I could do something myself by asking maintainers to update > >> packages what are in backports, but with another version then in > >> testing. Good idea? > > > > We had this, no one cared about it, we asked for it and no one was > > interested. > > I guess, somebody should work on it. Write e-mails etc. > I care about it, and I guess more people do. > > When I write an e-mail to a DD and ask for a newer backport, most DD's > are very friendly and like to do that. > > I generally think it's a good thing to have the same packages in > backports as in testing. > > > Therefore for backports.d.o this is currently a no-go. > > I ask for it in the Debian-LTS list, not in de backports list. Thats fine, I just wanted to write an official backports statement. Otherwise the next will say: ask on the backports mailinglist. > Maybe backports should remove packages what are removed from testing. > Or where the version is not the same as in testing (after some time). We usually do that. Alex
Re: Backports LTS security support
On Fri, 08 Feb 2019, Paul van der Vlis wrote: > Hello, > > I would like to have LTS support for backports. On most systems I use > one or more packages from backports. > > When the same version of a package is in use in the next version of > Debian, I guess backporting them is -in most cases- not a big problem. > > I am interesting if it would be a good idea to ask maintainers in the > freeze-phase to put the same versions in stable-backports, if the > package is in backports. > > Maybe we could say somewhere in the future: LTS supports backports, but > only when the same version of a package is in the next Debian version. > With some exceptions. > > Maybe I could do something myself by asking maintainers to update > packages what are in backports, but with another version then in > testing. Good idea? We had this, no one cared about it, we asked for it and no one was interested. Therefore for backports.d.o this is currently a no-go. Alex - Backports ftpmaster
Re: DLAs not arriving at my mailbox and I think it may be a general issue
On Sun, 03 Feb 2019, Ola Lundqvist wrote: > Hi > > I can understand the view that gmail, yahoo and others are to blame for the > lost message. It is after all that service that rejected it. I do however > think we need to live with the fact that we may have users that tend to use > such services. If it is just for me I can safely ignore the problem. These > emails are not that valuable to me, really. The reason why I brought this > up was to ensure that our users do not have the same problem. > If we conclude that this is not so important, then I can live with it. > > I cannot tell for sure what the fault was with that email. I'm not even > sure there were any specific fault with it. It may have been the rate of > things arriving or some similar factor. > > What I can tell is that lists.d.o do not follow gmail recommendations. And > some of them are generally good to avoid spam and other stuff. Several of those recommendations are nonsense. > > First of all the reverse address is not the same as the forward address: > > ola@tigereye:~/git/security-tracker$ getent hosts 82.195.75.100 > 82.195.75.100 bendel.debian.org > ola@tigereye:~/git/security-tracker$ getent hosts bendel.debian.org > 2001:41b8:202:deb:216:36ff:fe40:4002 bendel.debian.org Like that one. > > I guess bendel has both IPv4 and IPv6. The reason why it was using IPv4 > this time was that my server do not have an IPv6 address. I guess this is > quite common too even though IPv6 gets more and more common these days. > > There is no SPF record for lists.debian.org. Should'nt we have that? no, the RFC says its not required. > > I guess these two problems above are a strong factor in this. > > And then finally the from address vary. I can understand that it may not be > the best to change that, but maybe we should have this as a per-list option. No chance. I would even leave the project when we start the *censored* of rewriting from addresses. Alex
Re: DLAs not arriving at my mailbox and I think it may be a general issue
On Sun, 03 Feb 2019, Ola Lundqvist wrote: > Hi Antoine and Alexander > > Alexander: > So what should we do to prevent this from happening? Don't use gmail or at least tell me what exactly was wrong on the mail. > > Antoine: > Thank you for pointing that out. > > I found this in the BTS: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830865 > Is this what you are referring to? That one is about alioth and bugs. The list relevant bug was https://bugs.debian.org/500965 Alex
Re: DLAs not arriving at my mailbox and I think it may be a general issue
On Sun, 03 Feb 2019, Antoine Beaupré wrote: > On 2019-02-03 22:09:20, Ola Lundqvist wrote: > > If someone have an idea on how I may have screwed this up myself I'm happy > > to know. :-) > > After a quick glance, this might be gmail obsessing over DMARC. Typical > problems all mailing lists providers have suffered since this infamous > standard came up - the workaround is usually to rewrite the From header > in mailing lists to be the list itself. > > I'm actually surprised to see that lists.debian.org hasn't implemented > such workarounds yet, I would think this is a very common occurence... > > Probably something to discuss with listmasters, but check in the BTS > first (lists.debian.org metapackage). We added several workarounds by no longer breaking signatures. We won't do any more workarounds. Alex - Debian Listmaster
Re: the way to enigmail: gnupg 2.1 backport considerations
On Mon, 19 Nov 2018, Antoine Beaupré wrote:
> On 2018-11-13 22:02:45, Ben Hutchings wrote:
> > On Tue, 2018-11-13 at 12:31 -0500, Daniel Kahn Gillmor wrote:
> >> On Mon 2018-11-12 15:16:39 -0500, Antoine Beaupré wrote:
> >>
> >> > * libgcrypt20 (part of GnuTLS, 1.6 -> 1.7)
> >>
> >> libgcrypt is not a part of GnuTLS. GnuTLS has used nettle instead of
> >> gcrypt for years. gcrypt is more properly "part of GnuPG" than anything
> >> else.
> >>
> >> basically, all of these libraries are gnupg libraries.
> >>
> >> It's a little bit distressing that upstream's attempt to split them out
> >> as distinct libraries (which i think was intended to make them more
> >> useful to other consumers) might be a roadblock on the way to updating
> >> GnuPG itself.
> >>
> >> Ben's suggestion of shipping them in a non-default location ("vendor
> >> bundling"?) sounds pretty dubious to me -- i wouldn't want to reason
> >> about (let alone vouch for) the upgrade path from such a hybridized
> >> variant of jessie to standard debian stretch myself.
> >
> > I was thinking that those libraries would be included in the same
> > binary package as /usr/bin/gpg2 and other executables, which would all
> > have a run-path set. No-one should need to set LD_LIBRARY_PATH so no
> > other executables would use those libraries, and the libraries would be
> > removed when the executables that use them are removed or replaced.
> >
> > Since gnupg2 actually spreads executables across multiple binary
> > packages, I realise the libraries would have to be an additional binary
> > package and that would remain after an upgrade. But it would be
> > harmless cruft that "apt autoremove" would deal with.
> >
> > (I assume that GnuPG 2.1 would be packaged as "gnupg2", replacing GnuPG
> > 2.0 since that is no longer supported upstream. If not then I do see a
> > problem of how to make, say, gnupg2.1 in jessie upgrade to gnupg2 in
> > stretch. But that's independent of the library issue.)
>
> I think this is overengineered. I still haven't heard exactly what the
> problem would be with upgrading those libraries. They are present in
> jessie-backports and presumably well tested. They are rarely directly
> consumed by third-parties and mostly encapsulated behind GPGME, at least
> that's my understanding. The SONAMEs don't change, so they should be
> backwards compatible anyways.
>
> Right?
>
> Doing otherwise would be a massive change and would mean we would be
> maintaining multiple copies of those four libraries in jessie, and in an
> obscure location as well. I don't know how we would proceed to do this
> as source packages anyways - would they all get merged into the gnupg2
> source package?
>
> In any case, I don't feel confident starting down that path and I'm
> running out of time for the month, so I'll let others figure that out
> for the next two weeks.
I can't stress thos often enough. Jessie-backports doesn't exist anymore.
They are unsupported for months and I do really hope that they get archived
soon.
Do NOT use it.
Alex - Debian Backports ftpmaster
Re: the way to enigmail: gnupg 2.1 backport considerations
On Mon, 12 Nov 2018, Antoine Beaupré wrote: > Hi, > > So I've been looking at Enigmail again, after a long journey helping > people in stable getting that stuff fixed. It's pretty obvious there's > no way to upload that without first doing a GnuPG 2.1 backport into > jessie. > > That, it turns out, requires *four* more source package > backports. Fortunately for us, *all* of those are already in > jessie-backports. They would, unfortunately, probably need to be > uploaded straight into jessie-security, however, if only for > consistency's sake. Not only for consistency, jessie-backports is closed and will (hopefully) get archived soon. Alex
Re: Removal of 'arm64' from debian-security repo breaks community projects
On Thu, 16 Aug 2018, Lee Jones wrote: > Good morning Debian LTS/Security Team(s), > > It has come to my attention that 'arm64' support was recently removed > from the debian-security repo [1]. After reading your announcement > [2] from June 1st it is clear that this is not a bug, but a deliberate > action/decision made by your good selves. Could I ask you to please > reconsider your position? This action breaks many community > projects, seen most clearly on the Docker Hub builder [3] where the > majority of the yellow (unstable) builds are the ones based on > Jessie. In these cases Docker Build's 'RUN' command will result in > failure after an error return from `apt update`. > > If you still decide that supporting 'arm64' as LTS is not the way to > go, is there any way you could simply not update the repo, rather than > totally removing it? This will ensure that the many community > projects based on Jessie will at least keep working, even if they are > no longer contain the latest and greatest security fixes. > > Any help would be gratefully received. Please don't add anyone on Cc that doesn't want to. Please remove massimo from your Cc list. We do have a removal request for that address now. Alex - Debian Listmaster
Re: Fwd: jessie-backports discontinued
On Fri, 27 Jul 2018, Paul van der Vlis wrote: > Op 27-07-18 om 11:35 schreef Alexander Wirt: > > On Fri, 27 Jul 2018, Paul van der Vlis wrote: > > > >> Hello, > >> > >> I saw the security support for jessie-backports has been stopped. > >> > >> To be honest, I did not realize that there is no LTS security support > >> for backports, and I do use it! > >> > >> Maybe it's an idea to find ways to add backports to the LTS support in > >> the future? > > We had ideas and discussed them on the backports list. There wasn't any > > interest, neither by users nor by dds. > > Maybe not many people read the backports list. > Or they think: still more work to do. > > For LTS it's something else, DD's get payed for the work they do. > > I am very interested in LTS support for backports. > (And I can make simple backports.) That will however not happen on debian-backports. Alex
Re: Fwd: jessie-backports discontinued
On Fri, 27 Jul 2018, Paul van der Vlis wrote: > Hello, > > I saw the security support for jessie-backports has been stopped. > > To be honest, I did not realize that there is no LTS security support > for backports, and I do use it! > > Maybe it's an idea to find ways to add backports to the LTS support in > the future? We had ideas and discussed them on the backports list. There wasn't any interest, neither by users nor by dds. Alex - backports ftpmaster
Re: Fwd: [Ticket#2018033089000104] Ticket Created: [SECURITY] [DLA 1332-1] libvncserver security update
On Sat, 31 Mar 2018, Abhijith PA wrote: > Hello. > I received this mail after sending DLA. Is it something set up by our > sponsors ? Or spam. Such autoresponders are not allowed on l.d.o. I unsubscribed the user from all lists. Alex - Debian Listmaster
Re: Extended Long Term Support for Wheezy
On Tue, 20 Feb 2018, Vincent Bernat wrote: > ❦ 20 février 2018 18:10 +0100, Raphael Hertzog : > > >> some of the LTS sponsors are looking to extend the support period of > >> Debian 7 Wheezy (from a few months up to a full year).i > > > > FWIW, I published a blog post with more details about how it will > > work from the sponsor's point of view: > > https://raphaelhertzog.com/2018/02/20/time-to-join-extended-long-term-support-for-debian-7-wheezy/ > > Limiting ELTS access to sponsors seem quite incompatible with using any > Debian resource for that. Is that really the meaning of the last > paragraph? It its true, please stop to use any debian resources. Thanks Alex signature.asc Description: PGP signature
Re: [SECURITY] [DLA 737-1] roundcube security update
On Fri, 09 Dec 2016, Markus Koschany wrote: > On 09.12.2016 11:23, Chris Lamb wrote: > > Hi Christoph, > > > >> will there also be a fixed wheezy-backports version? It is at 0.9.5. > > > > As this CVE/DLA is still fresh in my mind, I've gone ahead and uploaded a > > 0.9.5-1~bpo70+1.1 to wheezy-backports. > > > > Enjoy :) > > > > Hi, > > I cannot really recommend to use the wheezy-backports version of > roundcube. It is still affected by all the other security > vulnerabilities from the past. We had already talked about this to the > maintainers but they didn't take action to request its removal from > Debian. I wonder if we should do it now? I did it now. Alex - Backports ftpmaster signature.asc Description: PGP signature
Re: Archive of squeeze-lts ?
On Thu, 24 Mar 2016, Luke Hall wrote: > Hi, > > I'm seeing this when trying to fetch lts packages from > archive.debian.org at the moment. Anyone know a good contact for them? > > E: Release file expired, ignoring > http://archive.debian.org/debian/dists/squeeze-lts/Release (invalid > since 9d 1h 10min 4s) Thats expected and won't change. Time to upgrade. Alex signature.asc Description: PGP signature
Re: Please remove me from the list!
On Tue, 10 Mar 2015, Ben Hutchings wrote: > On Tue, 2015-03-10 at 12:59 +0100, Alexander Wirt wrote: > > On Tue, 10 Mar 2015, Abel Guzman wrote: > > > > > Good day, > > > > > > Thank you for your answer. > > > I have done the unsubscription procedure using both methods a few times > > > and > > > it does not work for me. > > > > > > I just did it again, so if your receive this message there should be a > > > problem, isnt it? > > Thats wrong. You can post to the list without beeing a subscriber. > > > > And I checked the subscriber lists, noone from your domain is subscribed to > > any of our lists. > > So I would guess Abel is subscribed under another address that is > forwarding to his current one. The forwarding address should appear > somewhere in the 'Received' header lines. If he still receives mail he should check the Return-Path of a mail received from the list. It includes the subscriber address. Alex pgp9mkuJRrsIi.pgp Description: PGP signature
Re: Please remove me from the list!
On Tue, 10 Mar 2015, Abel Guzman wrote: > Good day, > > Thank you for your answer. > I have done the unsubscription procedure using both methods a few times and > it does not work for me. > > I just did it again, so if your receive this message there should be a > problem, isnt it? Thats wrong. You can post to the list without beeing a subscriber. And I checked the subscriber lists, noone from your domain is subscribed to any of our lists. Alex - Debian Listmaster -- To UNSUBSCRIBE, email to debian-lts-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150310115920.ge14...@formorer.de
Re: Bug#760358: please add [SECURITY] subject prefix for debian-lts-announce
On Wed, 03 Sep 2014, Thijs Kinkhorst wrote: > Package: lists.debian.org > Severity: wishlist > > Hi, > > Can you please configure the debian-lts-announce list so it has a subject > prefix "[SECURITY] ", in the same way that debian-security-announce has? > > Current difference between d-s-a and d-l-a: > > Subject: [SECURITY] [DSA 3017-1] php-cas security update > Subject: [DLA 43-1] eglibc security update > > Desired situation: > > Subject: [SECURITY] [DSA 3017-1] php-cas security update > Subject: [SECURITY] [DLA 43-1] eglibc security update Done, but untested. Please test this as soon as possible. Alex Alex -- To UNSUBSCRIBE, email to debian-lts-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140903113122.gb24...@lisa.snow-crash.org
Re: DLA documented
On Tue, 15 Jul 2014, Holger Levsen wrote: > Hi, > > On Dienstag, 15. Juli 2014, Moritz Muehlenhoff wrote: > > I don't think we should impose restrictions on the format of the mails. > > I think we absolutly should. We want consistend announcements, don't we? > > > If > > we want to welcome maintainers not part of the LTS team to take care of > > packages in Debian LTS, we should not make this needlessly difficult. > > Sure! But I think we can do both. > > > Let's not mimick the existing security.debian.org infrastructure too much, > > but rather have a look on how can create cleaner solutions from scratch > > (and retrofit them into security.debian.org once they've proven > > themselves): > > I also agree with this. > > > If IDs are important to people to have a specific identifier, we should > > rather solve this technically: The script which checks the PGP signature > > could simply increment the ID internally and rewrite the subject with [DLA > > $ID]. This saves people from all hassle with allocating IDs and it's free > > of race conditions in assigning IDs. > > listmasters, how feasible do you think it is? I'm all for automating the > generation of proper announcements! (But I also think that we should use > other > means to achieve consisten announcements until we got there.) if someone provides something that works with procmail: sure. But please don't expect us to write something for you. You need of course save the id somewhere, do locking and so on. Alex pgpjjTxt2rGjS.pgp Description: PGP signature
Re: Fwd: cacti security update
On Tue, 15 Jul 2014, Moritz Muehlenhoff wrote: > On Mon, Jul 14, 2014 at 09:20:54PM +0200, Paul Gevers wrote: > > Hi all, > > > > On 5 July, I sent the attached security update to the announce list. It > > seems to have never reached that list. Could somebody enlighten me and > > tell me what I did wrong? > > Only list masters can investigate this. Please send the message-ID of the > mail as it left your system to listmas...@lists.debian.org or contact > them in #debian-lists > > Didn't you receive a bounce? If not, we should fix this. The system doesn't send bounces. Alex -- To UNSUBSCRIBE, email to debian-lts-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140715052153.gd4...@formorer.de
Re: DLA documented
On Mon, 14 Jul 2014, Moritz Mühlenhoff wrote: > On Mon, Jul 14, 2014 at 05:06:26PM +0200, Holger Levsen wrote: > > Hi, > > > > Alexander Wirt just offered/suggested to reject mails not conforming to a > > certain subject format (eg including a DLA ID) as well as unsigned mails. > > (I'd > > suggest to only allow mails signed by keys able to upload.) > > I thought "signed by a DD" is already a requirement for the LTS announce list? in act its: /org/keyring.debian.org/keyrings/debian-nonupload.gpg:/org/keyring.debian.org/keyrings/debian-keyring.gpg Alex -- To UNSUBSCRIBE, email to debian-lts-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140714164506.ga4...@formorer.de
Re: Implications of LTS on backports
On Fri, 23 May 2014, Dominic Hargreaves wrote:
> Hi,
>
> With LTS support being planned for squeeze, it would be good to also keep
> squeeze-backports{,-sloppy} open for business (for packages from wheezy,
> of course); have there been any discussions about this? sarge and etch
> backports got closed at the same time as security support was terminated
> for those releases, but it looks like lenny backports closure followed the
> move of lenny to archive.debian.org. (For that matter I'm assuming that
> squeeze itself won't be archived during the LTS period!)
I never questioned that, as long as squeeze is supported (and I count lts as
support) backports will support it too.
Alex
--
To UNSUBSCRIBE, email to debian-lts-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140523115241.ga6...@lisa.snow-crash.org
