[03:15] How to remove the oem-priority bug_task from https://bugs.staging.launchpad.net/oem-priority/+bug/1900169 by Launchpad API? [03:15] Ubuntu bug 1900169 in juju "Creating a controller leads to eternal hang (no timeout)" [Medium,Confirmed] [03:23] I found bugtask.lp_delete() on http://bazaar.launchpad.net/~lazr-developers/launchpadlib/trunk/view/head:/contrib/delete_bugtasks.py. [08:30] hey there, I just did an upload to Ubuntu which got approved (it's showing in the queue, https://launchpad.net/ubuntu/groovy/+queue?queue_state=1&queue_text=) but I didn't get an email and the #ubuntu-release bot didn't notify about it either, so I was wondering if there is maybe an issue on the launchpad side with upload notifications? [09:26] it worked for other uploads, but langpacks are special to avoid spam right? said differently unping :-) [09:27] I think there are some notification oddities around langpacks, yes [09:27] Or more specifically around anything in Section: translations [09:28] https://git.launchpad.net/launchpad/tree/lib/lp/soyuz/mail/packageupload.py#n314 [09:30] cjwatson, thx === cpaelzer__ is now known as cpaelzer [15:33] cjwatson, wgrant: recent chat from -hardened, just FYI: https://paste.ubuntu.com/p/zpdNwDr24B/ [15:44] We're aware [15:44] I agree we need to fix it, but it needs coordination with the client side too [15:45] Since apt doesn't have a way to deal with its end of key rotation, so actually doing it would be very disruptive at the moment [15:47] i agree it would be disruptive at the moment, as it would have been 5 years ago, when it was first pointed out on the bug tracker that "1024-bit RSA was deprecated years ago by NIST[1], Microsoft[2] and more recently by others[3]." [15:48] This is not likely to be a very productive discussion, I see [15:48] i understand you cannot change apt, and it may require coordination if the discruption is to be prevented. [15:48] my intent was not to blame, but to point out that it's been a long time. [15:49] I generally don't find pointing out the age of bug reports to be especially productive [15:49] It's always necessary to triage, and sometimes things slip through for one reason or another [15:50] Perhaps the LP team can start a productive conversation with juliank at some point about what we'd need to do to make key rotation happen [15:50] I would prefer it not to be now since I'm about an hour away from the end of my week [15:50] heh [15:50] I'm on a break before a meeting about to hit my indoor cycling [15:52] I don't mind changing apt such that 3rd party repositories can do key rotations [15:52] Another thing we could possibly do to dodge the issue in the short term and deal with xnox's problem would be to adjust the way keys are reused between multiple PPAs owned by the same user; we could for example only reuse keys that meet current standards [15:53] That would probably be much easier and doable immediately, so I'll put that on my near-term to-do list [15:53] Don't reuse keys at all? [15:53] Like, add-apt-repository stores them per ppa anyway [15:53] Also a possibility [15:53] But I'd need to apply Chesterton's Fence [15:54] (i.e. the general principle that you should find out why it was that way before changing it) [15:55] It's possible it was just some kind of load concern in which case it's probably no longer an issue [16:01] the age of bug reports seem to matter (to me, anyways) when they have security impact and it means the window of opportunity for attacks on weak crypto extends, and the ease by which those can be carried out keeps decreasing (improved cryptoanalysis, new and more potent hardware). [16:01] i really didn't mean to trigger bad feelings on this (it appears these were present previously, though). i really just would love to see this improve. so, if i may: pleeeease cooperate and see if you can contribute towards a way forward which will work for everyone (after compromising). [16:14] Believe me I have personally been working extremely hard to sort out various bits of our crypto - it's not something I discount [16:17] I don't believe 1024-bit RSA has yet been successfully attacked directly, though I agree that it's looking shaky enough that the recommendations for a longer key length are very sensible [16:17] So my priority has been to deal with things that are worse than that [16:18] E.g. at present addressing the issue brought up recently that our SSH endpoints don't implement the recent rsa-sha2-* extensions and so are effectively still using SHA-1 when RSA public keys are used [16:19] (As well as in parallel working on the complicated pile of stuff necessary to be able to support Ed25519) [16:20] Being humans with finite time this is the sort of prioritisation that we generally have to do, irrespective of the age of reports [16:21] But in this particular case there do seem to be things we can do to improve things relatively immediately without needing to get into complex coordination issues [16:24] * cjwatson finds https://git.launchpad.net/launchpad/commit?id=9a31edbd8c8c34f39e06a13ccb0fd780cfd8cb10. The closest thing to a rationale there is "The *trust* belongs to the archive maintainer (owner) not the archive itself", which is technically true but the point that add-apt-repository stores them separately anyway stands; that was early in the evolution of PPAs so it seems reasonable to me to [16:24] * cjwatson override that decision [16:25] (And also, to clarify, I don't think there are any bad feelings between LP and apt. It's just a somewhat tricky technical problem to solve) [16:40] No doubt there. It seems that not enough manpower has been going into maintaining the infrastrucutre, for years. [16:43] There was a period of a few years when it was severely understaffed, and we're doing a lot of catch-up from that. [16:43] For the last year or so we've had a proper team and development roadmap and such. [16:45] But obviously one can't just catch up instantly. [16:45] oh nice, that's good news! [16:46] well, news to me, anyways :) [16:47] A lot of the work involved here has been somewhat internal and maybe less visible, but aimed at lowering development friction - upgrading our internal infrastructure, library upgrades, training, distributing support duties, all that sort of thing [17:56] I don't need it looked at specifically (I can just wait), but https://launchpad.net/~oddbloke/+archive/ubuntu/gh608/+build/20171641 has been uploading for ~40mins (and should be a handful of MB at most). Just a heads-up in case there's something unexpected going on. [19:05] Odd_Bloke: It's done now; nothing unexpected particularly, just a bit of a backlog and some large uploads (that queue is processed serially, unfortunately) [19:08] Thanks! [22:08] tomreyn,juliank: BTW you did manage to nerdsnipe me into putting together a patch for https://bugs.launchpad.net/launchpad/+bug/1700167 to not reuse keys just before going on holiday [22:08] Ubuntu bug 1700167 in Launchpad itself "new PPAs are re-using old 1024-bit RSA signing keys" [High,In progress] [22:09] haha :) [22:12] wow, that's almost all tests, except for a big hunk of code removal [22:13] Launchpad has a *lot* of tests so this isn't too uncommon [22:14] And a lot of the really old code has tests written as horribly entangled doctests, so it can sometimes end up being quite involved to disentangle those [22:17] it certainly reminded me of the most recent launchpad merge request I read, which was something like 97 [22:17] 97% tests :) heh [22:18] Mostly we like it that way [22:19] I'd often like the tests to be better organised, but don't regret the proportion! [22:19] yeah, most people are dreaming they'd have more tests :) [22:20] dreaming about a better way to arrange the tests.. well done :)