Re: pound
On Mon, Jan 25, 2016 at 02:23:39PM +0100, Raphael Hertzog wrote: >On Mon, 25 Jan 2016, Brian May wrote: >> I tried to create an account, but this failed with a generic error; so I >> wondered if I already had an account (I don't think I do), and tried the >> forget password routine. I am wondering if it has detected a security >> violation and blocked my IP address. If so, seems a very paranoid >> server. > >Try to ask to w...@debian.org. Or directly to Paul Wise / Steve McIntyre >with the specifics of your problem. > >https://wiki.debian.org/DebianWiki/Contact#wiki-sys-admins I'm on the list already, in fact. :-) Brian - it's possible your address or address range is blocked due to spam. If you can give me your IP address (privately if you prefer), I can check on the server and fix things. -- Steve McIntyre93...@debian.org Debian wiki admin - wiki.debian.org
Re: Removal of 'arm64' from debian-security repo breaks community projects
On Thu, Aug 16, 2018 at 10:52:51AM +0100, 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. Hey Lee! I'm guessing that the list of LTS architectures for Debian 8 (Jessie) was just copied over from Debian 7 (Wheezy), and nobody thought to check it or update it. arm64 didn't exist at all in Jessie, so was simply overlooked here. I'm hoping it shouldn't be too hard to add arm64 into the list. However, we *really* should push people to update their software usage more frequently than this. Jessie was released more than 3 years ago, and even with LTS support I wouldn't recommend sticking there for arm64. Lots of fixes and updates won't flow back that far. -- Steve McIntyre, Cambridge, UK.st...@einval.com Armed with "Valor": "Centurion" represents quality of Discipline, Honor, Integrity and Loyalty. Now you don't have to be a Caesar to concord the digital world while feeling safe and proud.
Re: armel/armhf in stretch LTS
On Wed, Aug 29, 2018 at 11:02:59PM +0300, Adrian Bunk wrote: >On Fri, Aug 17, 2018 at 09:40:53AM +, Holger Levsen wrote: >>... >> also, https://wiki.debian.org/LTS/ since more than a year explained that >> jessie LTS would not support arm64, so again, plenty of warning. >>... > >Speaking about advance-warning, please remove armel and armhf from the >list of architectures planned for stretch LTS. > >Building armel or armhf in stretch on armv8 hardware is untested, >and for armhf there are known problems in unstable. > >The current 32bit armv7 builders are scheduld to be decommissioned >by DSA after the non-LTS lifetime of stretch, there won't be any >buildds suitable for building armel/armhf for stretch LTS. This is utterly premature and unwarranted. Don't be ridiculous. So long as there are people interested enough in LTS for those architectures to cover the work and costs, there's no reason to stop. -- Steve McIntyre, Cambridge, UK.st...@einval.com "Yes, of course duct tape works in a near-vacuum. Duct tape works anywhere. Duct tape is magic and should be worshipped." -― Andy Weir, "The Martian"
Re: armel/armhf in stretch LTS
On Wed, Aug 29, 2018 at 11:29:51PM +0300, Adrian Bunk wrote: >On Wed, Aug 29, 2018 at 09:07:45PM +0100, Steve McIntyre wrote: >> >> This is utterly premature and unwarranted. Don't be ridiculous. > >Personal attacks don't change the facts. You *are* being ridiculous. You're claiming to know ~2 years early what we'll end up with. >> So long as there are people interested enough in LTS for those >> architectures to cover the work and costs, there's no reason to stop. > >"work" would include that there have to be buildds running and >maintained outside the Debian infrastructure. > >"work" would also include that every package built by these buildds will >have to be manually signed by a DD before it can enter stretch-security, >similar to what is currently done for kfreebsd-*. > >This would not be completely imposible, but an order of magnitude >more "work and costs" than for an architecture that has normal >DSA-maintained buildds. Enjoy your preconceptions. *Nothing* of what you're writing here might actually be necessary. How about waiting a little to see how things develop? -- Steve McIntyre, Cambridge, UK.st...@einval.com "I've only once written 'SQL is my bitch' in a comment. But that code is in use on a military site..." -- Simon Booth
Confusing our users - who is supporting LTS?
Hi, I'm quite concerned by what I think is a user perception problem around LTS. When the LTS project started up, discussions made it clear that existing maintainers and teams were *encouraged* but not *required* to help with the LTS effort. Paid effort would be used to help fill in for security support, for example - the regular security team chose not to volunteer to extend security support. However, it's clear that this is not understood by all our users, and that is not a good state of affairs. It's causing confusion for users, and in turn causing pressure on existing volunteer maintainers to support LTS too. The *particular* example that I've just seen is in reference to our cloud images, but I can see it also coming in other areas which are outside of the normal role of package maintenance. At our cloud team sprint 2 weeks ago, we had a discussion and agreed as a team that we did not want to spend additional effort on supporting oldstable images beyond the normal release cycle. In the last few days, we've started removing links to our existing Jessie images so that users looking for Debian cloud images will find Stretch images in preference. The older downloads are still available, just not publicised so well - users can continue to use whatever they need. We've already had complaints today from confused AWS users that they're no longer finding the Jessie images. It seems that they're expecting to continue to use those Jessie images for the full LTS lifetime. Don't get me wrong - of course we also want to support our users. But we don't have an infinite amount of effort available. We have a lot of work in our plan for the upcoming Buster release. The more time we spend supporting older images, the less time we have to do that new work. There's only a limited supply of spoons to go round... So I'm worried that those of us who have *not* volunteered to support LTS are being pressured into spending our time on it anyway. What can we do to fix that? How/where do we clarify for our users (and developers!) what LTS means, and what expectations are fair? -- Steve McIntyre, Cambridge, UK.st...@einval.com "... 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: [SECURITY] [DSA 4371-1] apt security update
On Tue, Jan 22, 2019 at 01:44:12PM +, Ben Hutchings wrote: >On Tue, 2019-01-22 at 13:17 +0100, Yves-Alexis Perez wrote: >> - >> Debian Security Advisory DSA-4371-1 secur...@debian.org >> https://www.debian.org/security/Yves-Alexis Perez >> January 22, 2019 https://www.debian.org/security/faq >> - >> >> Package: apt >> CVE ID : CVE-2019-3462 >> >> Max Justicz discovered a vulnerability in APT, the high level package >> manager. >> The code handling HTTP redirects in the HTTP transport method doesn't >> properly >> sanitize fields transmitted over the wire. This vulnerability could be used >> by >> an attacker located as a man-in-the-middle between APT and a mirror to inject >> malicous content in the HTTP connection. This content could then be >> recognized >> as a valid package by APT and used later for code execution with root >> privileges on the target machine. >[...] > >This presumably needs to be fixed for jessie LTS as well, and I see >Chris Lamb has claimed it. > >However, APT is used during initial installation and we don't have any >provision for updating installer images during LTS. So we're either >going to have to revisit that or come up with some kind of workaround >for installation time. I can help with new jessie installation images, but it'll need a bit of prep work. debian-cd doesn't pull from security or lts by default. -- Steve McIntyre, Cambridge, UK.st...@einval.com "Managing a volunteer open source project is a lot like herding kittens, except the kittens randomly appear and disappear because they have day jobs." -- Matt Mackall
Re: [SECURITY] [DSA 4371-1] apt security update
On Wed, Jan 23, 2019 at 12:19:28AM +, Ben Hutchings wrote: >On Tue, 2019-01-22 at 13:50 +0000, Steve McIntyre wrote: >> >> I can help with new jessie installation images, but it'll need a bit >> of prep work. debian-cd doesn't pull from security or lts by default. > >Would it be any easier to stick with oldstable as a base and explicitly >replace specific packages? *possibly* yes. That's still code that needs writing, either way. -- Steve McIntyre, Cambridge, UK.st...@einval.com Can't keep my eyes from the circling sky, Tongue-tied & twisted, Just an earth-bound misfit, I...
Re: [SECURITY] [DSA 4371-1] apt security update
On Thu, Jan 24, 2019 at 12:39:29PM +0100, Emilio Pozuelo Monfort wrote: >Hi Steve, > >On 22/01/2019 14:50, Steve McIntyre wrote: >> On Tue, Jan 22, 2019 at 01:44:12PM +, Ben Hutchings wrote: >>> However, APT is used during initial installation and we don't have any >>> provision for updating installer images during LTS. So we're either >>> going to have to revisit that or come up with some kind of workaround >>> for installation time. >> >> I can help with new jessie installation images, > >That would be great! > >> but it'll need a bit >> of prep work. debian-cd doesn't pull from security or lts by default. > >Just to clarify: there is no separate -lts suite anymore, so it'd just need to >pull from security (which still needs changes as you mentioned). > >Can you give a pointer to the code where this is done? Perhaps we can help with >the necessary code changes if you would welcome that. There are a few places where debian-cd references the mirror, suite, etc. which is a bit awkward here. Thinking about this, the *easiest* way to do this would be to use the existing "local" support which can pull in a local repo of changed .debs and .udebs on top of the base Debian repo access. Simply setting up a local repo with the apt packages in wouldn't be too hard here, and would solve the initial installation problem. However, it might confuse people a little, and I'll admit it might look ugly too. I'll give it a try now... -- Steve McIntyre, Cambridge, UK.st...@einval.com Is there anybody out there?
Re: [SECURITY] [DSA 4371-1] apt security update
On Sun, Jan 27, 2019 at 06:33:29PM +, Steve McIntyre wrote: >On Thu, Jan 24, 2019 at 12:39:29PM +0100, Emilio Pozuelo Monfort wrote: >> >>Just to clarify: there is no separate -lts suite anymore, so it'd >>just need to pull from security (which still needs changes as you >>mentioned). >> >>Can you give a pointer to the code where this is done? Perhaps we >>can help with the necessary code changes if you would welcome that. > >There are a few places where debian-cd references the mirror, suite, >etc. which is a bit awkward here. Thinking about this, the *easiest* >way to do this would be to use the existing "local" support which can >pull in a local repo of changed .debs and .udebs on top of the base >Debian repo access. Simply setting up a local repo with the apt >packages in wouldn't be too hard here, and would solve the initial >installation problem. However, it might confuse people a little, and >I'll admit it might look ugly too. > >I'll give it a try now... And that worked on the first attempt. Using this approach, I've done jessie builds of the various LTS arches using casulana, the normal CD build machine. Resulting test output at http://cdimage.debian.org/cdimage/.jessie_release/debian-cd/ if you'd like to have a look. I've tested the amd64 netinst with no network connection (to ensure no updates from elsewhere), and it happily installed the right version of apt (1.0.9.8.5) seamlessly. If you're happy with this, let me know and I'll spin a new version ready for release (version 8.11.1, I guess?). -- Steve McIntyre, Cambridge, UK.st...@einval.com There's no sensation to compare with this Suspended animation, A state of bliss
Re: [SECURITY] [DSA 4371-1] apt security update
On Mon, Jan 28, 2019 at 12:26:54AM +, Steve McIntyre wrote: >On Sun, Jan 27, 2019 at 06:33:29PM +0000, Steve McIntyre wrote: >> >>I'll give it a try now... > >And that worked on the first attempt. Using this approach, I've done >jessie builds of the various LTS arches using casulana, the normal CD >build machine. Resulting test output at > > http://cdimage.debian.org/cdimage/.jessie_release/debian-cd/ > >if you'd like to have a look. I've tested the amd64 netinst with no >network connection (to ensure no updates from elsewhere), and it >happily installed the right version of apt (1.0.9.8.5) seamlessly. > >If you're happy with this, let me know and I'll spin a new version >ready for release (version 8.11.1, I guess?). Ping? -- Steve McIntyre, Cambridge, UK.st...@einval.com Google-bait: http://www.debian.org/CD/free-linux-cd Debian does NOT ship free CDs. Please do NOT contact the mailing lists asking us to send them to you.
Re: [SECURITY] [DSA 4371-1] apt security update
On Fri, Feb 08, 2019 at 11:23:54AM +0100, Emilio Pozuelo Monfort wrote: > >I have done an automated install (ncurses frontend, installing GNOME) using the >netinst/amd64 image, with an LVM encrypted volume. I have also tested the CD1 >media, using the graphical installer, doing an SSH server install using the >guided partitioning (full disk). Both installations went well and the systems >seem alright. > >Is there any more tests that you would suggest? If you don't have anything >particular in mind, I'd be happy to respin this as 8.11.1 and publish it. OK, that sounds fine. I've just started a build now as 8.11.1 for the 4 LTS arches. I'll do a little bit of smoke testing, then publish in the normal place (https://cdimage.debian.org/cdimage/archive) and report back. Next: live images? cloud images? -- Steve McIntyre, Cambridge, UK.st...@einval.com You lock the door And throw away the key There's someone in my head but it's not me
Re: [SECURITY] [DSA 4371-1] apt security update
On Mon, Feb 11, 2019 at 01:38:05AM +, Steve McIntyre wrote: >On Fri, Feb 08, 2019 at 11:23:54AM +0100, Emilio Pozuelo Monfort wrote: >> >>I have done an automated install (ncurses frontend, installing GNOME) using >>the >>netinst/amd64 image, with an LVM encrypted volume. I have also tested the CD1 >>media, using the graphical installer, doing an SSH server install using the >>guided partitioning (full disk). Both installations went well and the systems >>seem alright. >> >>Is there any more tests that you would suggest? If you don't have anything >>particular in mind, I'd be happy to respin this as 8.11.1 and publish it. > >OK, that sounds fine. I've just started a build now as 8.11.1 for the >4 LTS arches. I'll do a little bit of smoke testing, then publish in >the normal place (https://cdimage.debian.org/cdimage/archive) and >report back. Now done. -- Steve McIntyre, Cambridge, UK.st...@einval.com "I suspect most samba developers are already technically insane... Of course, since many of them are Australians, you can't tell." -- Linus Torvalds signature.asc Description: PGP signature
Re: [SECURITY] [DSA 4371-1] apt security update
On Mon, Feb 11, 2019 at 01:58:24PM +0100, Emilio Pozuelo Monfort wrote: >On 11/02/2019 02:38, Steve McIntyre wrote: >> >> Next: live images? cloud images? > >I found cloud images for openstack in > >https://cloud.debian.org/images/cloud/OpenStack/archive/ ACK. >But can't find any jessie live images in > >https://cdimage.debian.org/debian-cd/ > >Are those archived somewhere else? Under http://cdimage.debian.org/cdimage/archive/ alongside the installer images. >For any of those, I suppose users could update apt following the >upgrade instructions. However, it wouldn't hurt to have updated >images with the new apt. I'd be happy to test any new images if you >can fire a build. May be a few days, we have the stretch point release this weekend and that's my priority. -- Steve McIntyre, Cambridge, UK.st...@einval.com Mature Sporty Personal More Innovation More Adult A Man in Dandism Powered Midship Specialty signature.asc Description: PGP signature
Re: recent DLAs not yet on www.debian.org
On Mon, Mar 04, 2019 at 01:22:27PM +0100, Markus Koschany wrote: > > >Am 04.03.19 um 13:13 schrieb Holger Levsen: >> Hi Markus, >> >> On Mon, Mar 04, 2019 at 01:06:07PM +0100, Markus Koschany wrote: >>>> the following recent DLAs are missing on www.debian.org currently: >>> I can't push to the webmaster-team repository. >>> GitLab: You are not allowed to push code to this project. >> >> did you read the URL I linked? >> >> if yes, any ideas how to make it more obvious what to do? >> >> if not, please do. > >Holger, I did read > > >https://wiki.debian.org/LTS/Development#Publishing_updates_on_the_website > >but I have no permission to push to > >https://salsa.debian.org/webmaster-team/webwml > >Someone has to grant all of us write permissions. > >If you want to create merge requests, then it should be mentioned but I don't >really >think that this is an efficient way. I doubt this is the workflow of the >security team. I've just granted you access to webmaster-team... -- Steve McIntyre, Cambridge, UK.st...@einval.com "Managing a volunteer open source project is a lot like herding kittens, except the kittens randomly appear and disappear because they have day jobs." -- Matt Mackall
Re: New buster-lts upload of shim
On Tue, Jan 31, 2023 at 07:13:05PM +0100, Salvatore Bonaccorso wrote: >Hi Steve, > >On Tue, Jan 31, 2023 at 03:56:55PM +0000, Steve McIntyre wrote: >> Hey folks, >> >> I've just uploaded a new shim update for buster, based on the latest >> update in unstable today. Please accept it quickly so we can get the >> binaries out and signed ASAP? > >The upload is already accepted, but I'm including as well the LTS list >for information (as the update should be accompanied with a DLA >describing the update). OK. >I assume for bullseye this is material for a point release, right? Correct, yes! -- Steve McIntyre, Cambridge, UK.st...@einval.com "Yes, of course duct tape works in a near-vacuum. Duct tape works anywhere. Duct tape is magic and should be worshipped." -― Andy Weir, "The Martian"
Re: New buster-lts upload of shim
On Wed, Feb 01, 2023 at 01:18:46AM +0530, Utkarsh Gupta wrote: >Hi Steve, > >On Tue, Jan 31, 2023 at 11:43 PM Salvatore Bonaccorso >wrote: >> > I've just uploaded a new shim update for buster, based on the latest >> > update in unstable today. Please accept it quickly so we can get the >> > binaries out and signed ASAP? >> >> The upload is already accepted, but I'm including as well the LTS list >> for information (as the update should be accompanied with a DLA >> describing the update). > >Thank you for the upload. I can prepare the paperwork but can you >point out what bugs we're fixing in this update? I need to write >something in the advisory. :) It will eventually (once we get the signed version through) fix a few bugs, such as (skimming the BTS): * #995940 * #995155 and maybe others. More importantly, it's needed to keep us updated with recent shim requirements so Secure Boot will continue to work. Our older shim binaries are at risk of being blocked soon-ish. I'd be tempted to hold back on the DLA and write a single one for shim and shim-signed when that turns up. -- Steve McIntyre, Cambridge, UK.st...@einval.com Dance like no one's watching. Encrypt like everyone is. - @torproject
Re: New buster-lts upload of shim
Hey all! On Tue, Jan 31, 2023 at 09:18:04PM +0100, Salvatore Bonaccorso wrote: >Utkarsh, > >On Tue, Jan 31, 2023 at 08:00:30PM +0000, Steve McIntyre wrote: >> On Wed, Feb 01, 2023 at 01:18:46AM +0530, Utkarsh Gupta wrote: >> >Hi Steve, >> > >> >On Tue, Jan 31, 2023 at 11:43 PM Salvatore Bonaccorso >> >wrote: >> >> > I've just uploaded a new shim update for buster, based on the latest >> >> > update in unstable today. Please accept it quickly so we can get the >> >> > binaries out and signed ASAP? >> >> >> >> The upload is already accepted, but I'm including as well the LTS list >> >> for information (as the update should be accompanied with a DLA >> >> describing the update). >> > >> >Thank you for the upload. I can prepare the paperwork but can you >> >point out what bugs we're fixing in this update? I need to write >> >something in the advisory. :) >> >> It will eventually (once we get the signed version through) fix a few >> bugs, such as (skimming the BTS): >> >> * #995940 >> * #995155 >> >> and maybe others. More importantly, it's needed to keep us updated >> with recent shim requirements so Secure Boot will continue to >> work. Our older shim binaries are at risk of being blocked soon-ish. >> >> I'd be tempted to hold back on the DLA and write a single one for shim >> and shim-signed when that turns up. > >Some helpful context might be here: >https://lists.debian.org/debian-boot/2023/01/msg00221.html > >For the DLA, I think the situation is very similar to grub or linux, >only for the main source package the advisory is actually issued, but >not for the signed packages (but I might have missunderstood what you >wanted to propose). As you'll have probably seen, I've uploaded shim-signed last night. Next up, some grub updates... -- Steve McIntyre, Cambridge, UK.st...@einval.com 'There is some grim amusement in watching Pence try to run the typical "politician in the middle of a natural disaster" playbook, however incompetently, while Trump scribbles all over it in crayon and eats some of the pages.' -- Russ Allbery
