Re: [SECURITY] [DLA 2441-1] sympa security update
On 2020-11-09 14:04:02, Sylvain Beucler wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > - - > Debian LTS Advisory DLA-2441-1debian-lts@lists.debian.org > https://www.debian.org/lts/security/ > November 09, 2020 https://wiki.debian.org/LTS > - - > > Package: sympa > Version: 6.2.16~dfsg-3+deb9u4 > CVE ID : CVE-2018-1000671 CVE-2020-26880 > Debian Bug : 908165 972189 What's up with those bug reports? #908165 refers to CVE-2018-1000671 but #972189 refers to CVE-2020-10936, not CVE-2020-26880. Also, CVE-2020-26880 is marked as unfixed in the security tracker (and the upstream bugtracker), but not CVE-2020-10936... Which one is which? Is the sympa package in Debian LTS still vulnerable to privilege escalation? A. -- The true revolutionary is guided by a great feeling of love. - Ernesto "Che" Guevara signature.asc Description: PGP signature
Re: heads up: DLA should now be published on the website
On 2019-02-21 18:18:06, Holger Levsen wrote:
> Hi Antoine,
>
> On Mon, Feb 18, 2019 at 04:10:47PM -0500, Antoine Beaupré wrote:
>> But my little finger tells me there are many DLAs still missing from the
>> website. So even if/when the above MR does get merged, more entries will
>> be missing. So someone will need to make sure to run the check script to
>> make sure no entries are missing regularly, see also:
>> https://salsa.debian.org/webmaster-team/cron/merge_requests/1
>
> I've looked at this script now, it works nicely, just our results are
> not so good yet:
>
> ~/Projects/debian-www/webwml$ ../cron/parts/10-check-advisories 2>&1 |wc -l
> 314
> ~/Projects/debian-www/webwml$ ../cron/parts/10-check-advisories --mode DLA
> 2>&1 |wc -l
> 1762
> ~/Projects/debian-www/webwml$ ../cron/parts/10-check-advisories --mode DLA
> 2>&1 | head -10
> ERROR: .data or .wml file missing for DLA 1685-1
> ERROR: .data or .wml file missing for DLA 1684-1
> ERROR: .data or .wml file missing for DLA 1683-1
> ERROR: .data or .wml file missing for DLA 1660-2
> ERROR: .data or .wml file missing for DLA 1682-1
> ERROR: .data or .wml file missing for DLA 1681-1
> ERROR: .data or .wml file missing for DLA 1680-1
> ERROR: .data or .wml file missing for DLA 1679-1
> ERROR: .data or .wml file missing for DLA 1678-1
> ERROR: .data or .wml file missing for DLA 1677-1
> debian-work:~/Projects/debian-www/webwml$
>
> -> this script is incorrect/broken for DLAs it seems, as
> https://www.debian.org/lts/security/ does list the DLAs 1677-1681,
> just DLAs 1682-1685 are missing. And they are called DLA-1234 there,
> not "DLA 1234-1"...
Weird. Is your local checkout up to date? What if you run in debug mode?
> Also, if this merge request would be merged, it would just run it in
> normal, DSA, mode. Do you have a suggestion how to run it in DLA mode?
We could simply change the default here:
parser.add_argument('--mode', default='DSA', choices=('DSA', 'DLA'),
help='which sort of advisory to check (default:
%(default)s)') # noqa: E501
a.
--
If you have come here to help me, you are wasting our time.
But if you have come because your liberation is bound up with mine, then
let us work together.- Aboriginal activists group, Queensland, 1970s
(early) monthly report
Hi all, Here's my early LTS report. The TL;DR: is: * website work * python-gpg * golang * libarchive * netmask * libreoffice * enigmail # Website work I again worked on the website this month, doing one more mass import ([MR 53][]) which was finally merged by Holger Levsen, after I [fixed an issue with PGP signatures][] showing up on the website. [fixed an issue with PGP signatures]: https://salsa.debian.org/webmaster-team/webwml/merge_requests/51 I also polished the misnamed "audit" script that checks for missing announcements on the website and published it as [MR 1][] on the "cron" project of the webmaster team. It's still a "work in progress" because it is still too noisy: there are a few DLAs missing already and we haven't published the latest DLAs on the website. [MR 1]: https://salsa.debian.org/webmaster-team/cron/merge_requests/1 [MR 53]: https://salsa.debian.org/webmaster-team/webwml/merge_requests/53 The remaining work here is to automate the import of new announcements on the website ([bug #859123][]). I've done what is hopefully the [last mass import][] and updated the workflow in the wiki. Finally, I have also done a bit of [cleanup][] on the website that was necessary after the mass import which also required [rewrite rules][] at the server level. Hopefully, I will have this fairly well wrapped up for whoever picks this up next. [rewrite rules]: https://salsa.debian.org/anarcat/dsa-puppet/merge_requests/1 [cleanup]: https://salsa.debian.org/webmaster-team/webwml/merge_requests/55 [last mass import]: https://salsa.debian.org/webmaster-team/webwml/merge_requests/58 [bug #859123]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859123 # Python GPG concerns Following a new vulnerability (CVE-2019-6690) disclosed in the python-gnupg library, I have [expressed concerns][] at the security reliability of the project in future updates, refering to wider issues identified by Isis Lovecroft in [this post][]. I suggested we should simply drop security support for the project, citing it didn't have many reverse dependencies. But it seems that wasn't practical and the [response][] was that it was actually possible to keep on maintaining it an such an update was issued for jessie. [response]: https://lists.debian.org/20190209103913.e45eqo3gax5g3...@manillaroad.local.home.trueelena.org [this post]: https://blog.patternsinthevoid.net/pretty-bad-protocolpeople.html [expressed concerns]: https://lists.debian.org/87r2cj4kg2@curie.anarc.at # Golang concerns Similarly, I have [expressed more concerns][] about the maintenance of Golang packages following the disclosure of a vulnerability (CVE-2019-6486) regarding elliptic curve implementations in the core Golang libraries. An update (DLA-1664-1) was issued for the core, but because Golang is statically compiled, I was worried the update wasn't sufficient: we also needed to upload updates for any build dependency using the affected code as well. [expressed more concerns]: https://lists.debian.org/87sgx0czxg@curie.anarc.at Holger asked the golang team for help and i also asked on irc. Apparently, all the non-dev packages (with some exceptions) were binNMU'd in stretch but the process needs to be clarified. I also wondered if this maintenance problem could be resolved in the long term by switching to dynamic linking. Ubuntu tried to switch to dynamic linking but abandoned the effort, so it seems Golang will be quite difficult to maintain for security updates in the forseeable future. # Libarchive updates I have reproduced the problem described in CVE-2019-120 and CVE-2019-119 in jessie. I published a fix as [DLA-1668-1][]. I had to build the update without sbuild's overlay system (in a tar chroot) otherwise the cpio tests fail. [DLA-1668-1]: https://lists.debian.org/20190207192754.ga14...@curie.anarc.at # Netmask updates This one was minimal: a patch was [sent by the maintainer][] so I only wrote and sent [DLA 1665-1][]. Interestingly, I didn't have access to the `.changes` file which made writing the DLA a little harder, as my workflow normally involves calling `gen-DLA --save` with the .changes file which autopopulates a template. I learned that `.changes` files are normally archived on `coccia.debian.org` (specifically in `/srv/ftp-master.debian.org/queue/done/`), but not in the case of security uploads. [DLA 1665-1]: https://lists.debian.org/20190206222753.ga28...@curie.anarc.at [sent by the maintainer]: https://lists.debian.org/20190206005958.ga7...@debian.org # Libreoffice I once again tried to tackle an issue (CVE-2018-16858) with Libreoffice. The [last time][] I tried to work on LibreOffice, the test suite was failing and the linker was *crashing* after hours of compilation and I never got anywhere. But that was wheezy, so I figured jessie might be in better shape. [last time]: https://anarc.at/blog/2017-11-30-free-software-activities-november-2017 I quickly got into trouble with sbuild: I ran ou
heads up: DLA should now be published on the website
On 2019-02-01 20:58:28, Holger Levsen wrote: > On Fri, Feb 01, 2019 at 01:58:04PM -0500, Antoine Beaupré wrote: [...] > can you please put that on wiki.d.o/LTS/Development?! This is now done. I added a new section to the wiki https://wiki.debian.org/LTS/Development#Publishing_updates_on_the_website The TL;DR: is that you now need to clone the main website and issue a merge request when you publish a DLA. Once you have a clone, it should be as simple as: parse-dla.pl git checkout -b DLA--Y git add 2019 git commit -m'DLA-XXX-Y' git push -u origin salsa mr I've done one more mass import, hopefully the last: https://salsa.debian.org/webmaster-team/webwml/merge_requests/58 But my little finger tells me there are many DLAs still missing from the website. So even if/when the above MR does get merged, more entries will be missing. So someone will need to make sure to run the check script to make sure no entries are missing regularly, see also: https://salsa.debian.org/webmaster-team/cron/merge_requests/1 Obviously, this workflow is not optimal and could be automated, see also #859123 (in CC). Thank you for your time. A. -- Omnis enim ex infirmitate feritas est. All cruelty springs from weakness. - Lucius Annaeus Seneca (58 AD)
Re: rssh security update breaks rsync via Synology's "hyper backup"
On 2019-02-18 09:27:37, Russ Allbery wrote: > Does this plan sound good to everyone? I'll follow up with the proposed > diffs for stable and oldstable. Works for me (LTS), although I won't be the one performing the upgrade (I've unclaimed the package for other reasons). Thanks for your work! A. -- Gods don't like people not doing much work. People who aren't busy all the time might start to think. - Terry Pratchett, Small Gods
Re: rssh security update breaks rsync via Synology's "hyper backup"
On 2019-02-14 10:08:40, Russ Allbery wrote: > Roman Medina-Heigl Hernandez writes: > >> Added Russ (rssh maintainer). > >> I cannot probe it but I guess chances are high that the issue is present >> both in stable and oldstable (I cannot find a good reason to filter >> different commands: solution should be the same or very similar) so I'm >> still keeping debian-security in the loop. > > That command line exactly is probably safe, but --daemon is definitely not > safe in combination with --config, -M, or --dparam. I'm not sure what > happens if you pass combinations like --server --daemon --address or > --port. Unfortunately, so far as I can tell, --server --daemon is not > even documented in the rsync man page as something you can do (I certainly > didn't know about its existence before this string of CVEs), so it's > pretty hard to figure out what its intended behavior is without doing a > deep dive into source code. > > We can try to make the command-line verification even more complex to try > to allow for more edge cases (another one just came up in an Ubuntu bug, > where libssh apparently sends arguments differently than scp itself does). > I'm not super-thrilled, but I guess I created this problem and signed up > for it, so I can try to keep playing whack-a-mole with new command-line > variations. > > Note that I'm definitely removing rssh from unstable and testing before > the next release as unsupportable. Upstream has orphaned it, and I think > the primitive that it's attempting to implement is fundamentally > impossible to maintain securely. So the long-term solution is for > everyone to migrate away from it, I'm afraid; the question is what to do > about stable (and oldstable). > > In this particular case, a simple command="rsync --server --daemon ." in > your ssh authorized_keys file might be a better solution than rssh. (But > be aware of CVE-2019-3463.) Thanks for the detailed analysis Russ! It does seem to be a bit of a whack-a-mole game that would be better solved by proper use of `command`... That said, if we do fix this in jessie, we should do it at the same time as the regression identified in stretch (DSA-4377-2). Russ, do you want to handle the Jessie update or should the LTS team do it? Should we wait for resolution on this issue before shipping the errata? Thanks! -- In serious work commanding and discipline are of little avail. - Peter Kropotkin
Re: Bug#859122: about 500 DLAs missing from the website
On 2019-02-12 08:13:18, Salvatore Bonaccorso wrote:
> Hi,
>
> On Sat, Feb 09, 2019 at 03:55:44AM +0100, Laura Arjona Reina wrote:
>> * We still need the Apache redirects, so the people that try the old
>> URLs (wether directly because they knew, or via the security tracker),
>> find the files they need. What we need to do is send a patch to
>>
>> https://salsa.debian.org/dsa-team/mirror/dsa-puppet/blob/master/modules/roles/templates/apache-www.debian.org.erb
>>
>> that sets the redirect from
>> https://www.debian.org/security/any_year/dla-whatever to
>> https://www.debian.org/security/lts/any_year/dla-whatever
>>
>> * Adaptation in the security tracker so the new URL paths are used from
>> now on is also needed.
>
> I have the attached patch commited in a local branch, but want first
> to confirm is this the final intended URL to reach the DLAs?
>
> Regards,
> Salvatore
> From ceda9e3d1fc38f505462bce8c0aa4cdd2b165d87 Mon Sep 17 00:00:00 2001
> From: Salvatore Bonaccorso
> Date: Tue, 12 Feb 2019 08:10:16 +0100
> Subject: [PATCH] Adapt URL to DLA advisories in a
> https://www.debian.org/security/lts/
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> As discussed in https://bugs.debian.org/859122 DLAs and DSAs will be
> separated in different supages. This needs adaption for the URL
> referenced in the source fields of the security-tracker for DLAs.
>
> Thanks: Laura Arjona Reina, Holger Levsen and Antoine Beaupré
> ---
> bin/tracker_service.py | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/bin/tracker_service.py b/bin/tracker_service.py
> index 971f4b4e38eb..a2ea755d8f39 100755
> --- a/bin/tracker_service.py
> +++ b/bin/tracker_service.py
> @@ -1574,7 +1574,7 @@ Debian bug number.'''),
> for (date,) in self.db.cursor().execute(
> "SELECT release_date FROM bugs WHERE name = ?", (dla,)):
> (y, m, d) = date.split('-')
> -return
> url.absolute("https://www.debian.org/security/%d/dla-%d";
> +return
> url.absolute("https://www.debian.org/security/lts/%d/dla-%d";
> % (int(y), int(number)))
> return None
I believe this is backwards, you want /lts/security, not /security/lts.
For example:
https://www.debian.org/lts/security/2019/dla-1659
I was also hoping to see the "errata number" in there, but it seems I
was mistaken.
--
L'ennui avec la grande famille humaine, c'est que tout le monde veut
en être le père.
- Mafalda
Re: concerns about the security reliability of python-gnupg
On 2019-02-09 11:39:18, Elena ``of Valhalla'' wrote: > On 2019-02-07 at 11:44:45 -0500, Antoine Beaupré wrote: >> Hi, >> >> Recently, python-gnupg was triaged for maintenance in Debian LTS, which >> brought my attention to this little wrapper around GnuPG that I'm >> somewhat familiar with. >> >> Debian is marked as "vulnerable" for CVE-2019-6690 in Jessie and Stretch >> right now, with buster and sid marked as fixed, as you can see here: >> >> https://security-tracker.debian.org/tracker/source-package/python-gnupg > > sorry, my fault for missing the CVE when uploading the new upstream > version; I will prepare the fix for stable(-security) ASAP. No problem! :) > I don't care enough about LTS to learn its upload procedures, but if > somebody is interested in doing it I can backport the patch and push it > to git, for them to upload. I'm sure people in the LTS team (including myself) would be happy to carry that torch any way you prefer. We can perform as much or as little as you want in the process. >> I'm concerned about the security of this project in general. Even though >> that specific instance might be fixed, there are many more bad security >> practices used in this project. A fork was created by Isis Agora >> Lovecruft to fix those issues: >> >> https://github.com/isislovecruft/python-gnupg/ > > AFAIK that fork is dead upstream, and it's not compatible with Vinay > Sajip's version, so it can't be used to satisfy the dependency in other > packages Maybe so, but the security concerns raised are serious and should be addressed. I'm surprised to hear it's not backwards-compatible, however... That is certainly a concern if we'd want to switch upstreams, but that's not exactly what I was proposing... Isis renamed their package to "pretty bad protocol" anyways, which makes it clear it's not designed to be a drop-in replacement. >> [...] >> I suspect many such issues could be identified formally in the >> python-gnupg package. > > My experience with upstream is that they are quite good at reacting to > issues that are raised on their bugtracker (and I'm happy to forward > them there from the debian BTS). > > On the other hand, they don't maintain a LTS version, so the fix will > happen in the latest release, and while I'm confident that many patches > will be backportable there is no guarantee that *all* of them would be, > especially to the version in oldstable. I am especially concerned about backporting fixes Isis identified. Those are far-ranging vulnerabilities that require massive code refactoring. I doubt those would be meaningfully backportable. >> But maybe, instead, we should just mark it as unsupported in >> debian-security-support and move on. There are few packages depending on >> it, in jessie: >> [...] >> in buster: >> [...] > > I think this list is missing something, maybe the reverse dependencies > of python3-gnupg: I know that gajim-pgp depends on it (and is in turn > recommended by gajim) at least in buster; earlier versions used an old > embedded copy of the same library, so this isn't really a "new" > dependency. I guess that's why I missed it in jessie - there are no rdeps for the py3 version in jessie... I'm not sure what to do next here. I just felt it was important to outline possibly fundamental problems with this package that are not currently mapped in the CVE process. Maybe that shouldn't lead to any action on our part, but I wanted people here to be aware of those concerns. A. -- Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. - Benjamin Franklin, 1755
Re: Bug#859122: about 500 DLAs missing from the website
On 2019-02-09 14:39:50, Holger Levsen wrote: > Hi Laura, > > many many thanks for your work on this, including and especially this > writeup! > > some comments below, where I dont say anything I mean 'yay"! :) > > On Sat, Feb 09, 2019 at 03:55:44AM +0100, Laura Arjona Reina wrote: >> * The /lts/security//index.*.html files show the last advisory for >> the cases where there are several files with the same beginning (e.g. >> for DSA- and DSA--2, both html files are generated, but the >> index only points to the -2 file). If this is not the intended >> behaviour, changes in index.wml and Makefiles are needed. > > I think we want the other DLAs linked from the indexes as well. > > shall we file a bug to not forget this? I looked into this, and couldn't figure it out. Please do file a bug for now, I have no idea how to fix this... [...] >> * We still need the Apache redirects, so the people that try the old >> URLs (wether directly because they knew, or via the security tracker), >> find the files they need. What we need to do is send a patch to >> >> https://salsa.debian.org/dsa-team/mirror/dsa-puppet/blob/master/modules/roles/templates/apache-www.debian.org.erb >> >> that sets the redirect from >> https://www.debian.org/security/any_year/dla-whatever to >> https://www.debian.org/security/lts/any_year/dla-whatever > > right. shall we file a bug to not forget this? Filed the patch here: https://salsa.debian.org/anarcat/dsa-puppet/merge_requests/1 Reviews welcome. I'm particularly doubtful of the dla-map thing - it's not in the source repo, but can I assume it's present on the website deployment? >> * Adaptation in the security tracker so the new URL paths are used from >> now on is also needed. > > right. shall we file a bug to not forget this? Sure, please do. A. -- People arbitrarily, or as a matter of taste, assigning numerical values to non-numerical things. And then they pretend that they haven't just made the numbers up, which they have. Economics is like astrology in that sense, except that economics serves to justify the current power structure, and so it has a lot of fervent believers among the powerful. - Kim Stanley Robinson, Red Mars
Re: Bug#859122: about 500 DLAs missing from the website
On 2019-02-09 03:55:44, Laura Arjona Reina wrote: > Hello all > > Holger Levsen merged the generated DLAs and I've worked to create the > /lts tree to show them separated from the DSA. I have moved to this new > /lts folder the DLAs from years 2014, 2015 and 2016 that we had already, > and remove them from the /security tree and removed references to DLAs > in the Makefiles/indexes in /security. > > I think it's mostly done, I've closed all the related MR except one, but > there are some small tasks left, that I hope we can solve together: > > * I have initially copied the content of /security/ to /lts/security, > removed subfolders that I think are not needed (audit, key-rollover, > oval, undated) and some other files that I think they were not needed > too. Then I did a search and replace DSA -> DLA, dsa- -> dla- in the > scripts, makefiles and indexes, and fixed the paths, and built locally > (with "make) and I couldn't spot errors, but I don't trust every file > that is currently in /lts/security is needed or has been used with my > "make" command, so a review of the folder (comparing it with /security) > done by an LTS or security team member, is welcome. It's true there's a lot of junk in there... I suspect most of the `.pl` scripts in there could actually be symlink to the main secteam scripts, because they are basically the same. I also suspect most of the stuff is unused, even from the secteam's point of view. For example, `check-cve-refs.pl` assumes there's a `security/data` directory in the website, which is not the case (anymore?). I would suggest removing those from at least the LTS section and have done so in the following MR: https://salsa.debian.org/webmaster-team/webwml/merge_requests/55 > * The README needs to be reviewed and adapted (I just did the search and > replace dsa -> dla and DSA -> DLA). Done as well in the same MR. > * I guess that parse-advisory.pl (and maybe others) can be removed, but > I was not confident to do it without advice. Done as well in the same MR. > * I didn't check the results of the generated RSS feeds. If anybody uses > RSS readers, a review is welcome too. It looks good to me here. > * The /lts/security//index.*.html files show the last advisory for > the cases where there are several files with the same beginning (e.g. > for DSA- and DSA--2, both html files are generated, but the > index only points to the -2 file). If this is not the intended > behaviour, changes in index.wml and Makefiles are needed. Ideally, we'd show both, is that possible? > * Please review the content (text, links) of these files: > > /lts/index.wml > /lts/security/index.wml > > I've tried to be short (for the case translators are fast and then you > decide to heavy rewrite, to not to loose much work). That makes sense to me. I wonder if we should link to the crossreferences.wml content, which is also relevant here. > * Translations have been handled, but I've left the *title* of these > files unchanged: > > french/lts/security/*/dla*.wml > russian/lts/security/*/dla*.wml > danish/lts/security/*/dla*.wml > japanese/lts/security/*/dla*.wml > > All those files have title "LTS Security Advisories from " (being > the year: 2014, or 2015, or 2016). I guess translators can do a > quick search and replace with the correct sentence and they don't need > to update the commit hash, that's already done. I'll contact translators > and point them to this message. Fair enough. > * This new /lts section of the website is not referenced yet in other > places of the Debian website. I'm not sure if it should be referenced in > /security, in /releases/, or in both. There is also the temptation > of creating a link in the homepage but there is also the suggestion of > reducing the links in the homepage, so... For now, I'll try to add it to > the sitemap and see how many references to the LTS wiki page we have > currently, to see if any of them can be replaced with link to this > section in the website. But I'll wait some days to do it because it's > not clear for me if you want to populate the section to cover all the > aspects of LTS, or keep it only/mainly for security stuff. I would avoid putting the LTS work too proeminently on the website at this point, to be honest. The goal of publishing those advisories there, for me, is coherence: they were already partly present and I wanted to have them *all* available *somewhere* with a predictable URL and RSS feeds (as opposed to, say the mailing list). We shouldn't get into the slippery debate of how much we want LTS content on the website, in my opinion. > * We still need the Apache redirects, so the people that try the old > URLs (wether directly because they knew, or via the security tracker), > find the files they need. What we need to do is send a patch to > > https://salsa.debian.org/dsa-team/mirror/dsa-puppet/blob/master/modules/roles/templates/apache-www.debian.org.erb > > that sets the redirect from > http
Re: faad2 and systemd: (semi)-automaticly unclaimed after 2 weeks of inactivity
On 2019-02-11 10:57:20, Holger Levsen wrote: > hi, > > I've just unclaimed faad2 and systemd as the last documented activity on these > packages was more than two weeks ago... > > If you intend to continue working on them, please just reclaim them and > update the note. Hehe... "arroseur arrosé" as they say in french. First time I'm affected by the auto-unclaimer, and I must say it's fair: I *have* been stalled on that one without progress for even more than two weeks now. The only reason why I still had it claimed is that I claimed it for *other* CVEs (DLA 1639-1) and didn't unclaim it when I was finished. The remaining work there dates back from November 2018, for those who are curious and tempted to give it a shot. I detailed part of the work I did on the tmpfiles.c stuff in message: https://lists.debian.org/87d0r07hl3@curie.anarc.at Long story short: the patch is too invasive to backport, so the next step is to try a backport of the entire tmpfiles.c file. It might sound crazy, but the individual systemd files like those are fairly well enclosed. The trick will be to work around new APIs and macros that are used in the new code, as opposed to properly cherry-picking the zillions of tiny and large patches applied across the history of that file to properly fix the bug. A. -- Only in the darkness can you see the stars. - Martin Luther King, Jr.
Re: (when?) do we (still) contact maintainers?
On 2019-02-07 18:32:39, Markus Koschany wrote: > Please do not CC me. I am subscribed. > > Am 07.02.19 um 18:23 schrieb Antoine Beaupré: > [...] >> Well, I don't think we should make such calls without announcing it and >> documenting the new workflow clearly, first off. >> >> Second, I think I mostly agree with you, but we need to be certain we >> won't upset other people's workflow, and this should be discussed. > > How does my decision to not contact a maintainer interrupt your > workflow? You can still contact the maintainer before you start to work > on a package. I meant the debian package maintainers, not mine. A. -- In a world where Henry Kissinger wins the Nobel Peace Prize, there is no need for satire. - Tom Lehrer
Re: (when?) do we (still) contact maintainers?
On 2019-02-07 17:58:48, Markus Koschany wrote: > Hello, > > Am 07.02.19 um 17:32 schrieb Antoine Beaupré: > [...] >> Am I missing something here? Did we change this practice, or is this an >> oversight? > > I have been part of the team for three years now, from my experience > almost all people are very happy when someone else fixes bugs in > oldstable. Most of the time we get either no response at all or someone > tells us to just go ahead. Since we have now the capacity to handle all > those issues all by ourselves, I don't find it no longer necessary to > contact every maintainer beforehand. Instead I decide on a case-by-case > basis. I would rather change the current recommendation and the > do-not-call list to a list of maintainers who want to be contacted first > before we work on their packages or have always prepared updates > themselves (e.g. postresql). This list will be quite short. Well, I don't think we should make such calls without announcing it and documenting the new workflow clearly, first off. Second, I think I mostly agree with you, but we need to be certain we won't upset other people's workflow, and this should be discussed. A. -- Tout ce qui n’est pas donné est perdu. - Proverbe indien
Re: concerns about the security reliability of python-gnupg
On 2019-02-07 16:48:56, Holger Levsen wrote: > On Thu, Feb 07, 2019 at 11:44:45AM -0500, Antoine Beaupré wrote: >> But maybe, instead, we should just mark it as unsupported in >> debian-security-support and move on. There are few packages depending on >> it, in jessie: > [...] >> in buster: >> Note that the list is (slowly) growing. > > marking it it unsupported in debian-security-support for jessie and > stretch might be the right step forward, but if if it's really as bad as > you describe, I think it should be kicked out of buster, instead of > carried on. That too. But I'd like to hear the maintainer's opinion before taking any more drastic measures. :) A. -- Les plus beaux chants sont les chants de revendications Le vers doit faire l'amour dans la tête des populations. À l'école de la poésie, on n'apprend pas: on se bat! - Léo Ferré, "Préface"
Re: concerns about the security reliability of python-gnupg
On 2019-02-07 11:44:45, Antoine Beaupré wrote: > https://dev.gentoo.org/~mgorny/articles/evolution-uid-trust-extrapolation.html > https://blogs.gentoo.org/mgorny/2019/01/29/identity-with-openpgp-trust-model/ Oops, that second link should have been: https://dev.gentoo.org/~mgorny/articles/attack-on-git-signature-verification.html A. -- Computer science is no more about computers than astronomy is about telescopes - E. Dijkstra
concerns about the security reliability of python-gnupg
Hi, Recently, python-gnupg was triaged for maintenance in Debian LTS, which brought my attention to this little wrapper around GnuPG that I'm somewhat familiar with. Debian is marked as "vulnerable" for CVE-2019-6690 in Jessie and Stretch right now, with buster and sid marked as fixed, as you can see here: https://security-tracker.debian.org/tracker/source-package/python-gnupg I'm concerned about the security of this project in general. Even though that specific instance might be fixed, there are many more bad security practices used in this project. A fork was created by Isis Agora Lovecruft to fix those issues: https://github.com/isislovecruft/python-gnupg/ Those patches were not merged back upstream, which is disputing isis' claims. The security issues found in the upstream package are partly documented here: https://blog.patternsinthevoid.net/pretty-bad-protocolpeople.html I am concerned that fixing only this specific CVE will give users a false sense of security, as many more similar issues might be lurking in the code. Having, myself, dealt with writing such a library (lesson learnt: don't do that), I can confirm it is very hard (if not impossible) to properly talk with GnuPG in a reasonable way. There is now a constant flow of vulnerabilities coming out that outline commonly made mistakes when trying to talk the line dialog with GnuPG. For example: https://dev.gentoo.org/~mgorny/articles/evolution-uid-trust-extrapolation.html https://blogs.gentoo.org/mgorny/2019/01/29/identity-with-openpgp-trust-model/ I suspect many such issues could be identified formally in the python-gnupg package. But maybe, instead, we should just mark it as unsupported in debian-security-support and move on. There are few packages depending on it, in jessie: Reverse Depends: Dépend: hash-slinger Dépend: pyspread in stretch: Reverse Depends: Casse: gnupg (<< 0.3.8-3) Recommande: python-sleekxmpp Dépend: pyspread Dépend: hash-slinger Dépend: goopg Dépend: deken in buster: Reverse Depends: Casse: gnupg (<< 0.3.8-3) Dépend: hash-slinger Dépend: goopg Recommande: python-sleekxmpp Dépend: python-rosbag Dépend: pyspread Note that the list is (slowly) growing. What do people think? A. -- L'adversaire d'une vraie liberté est un désir excessif de sécurité. - Jean de la Fontaine
(when?) do we (still) contact maintainers?
Hi, I was under the impression that we were supposed to contact maintainers when we add packages to dla-needed.txt, as part of the triage work. That is, at least, the method documented here: https://wiki.debian.org/LTS/Development#Triage_new_security_issues Confident that people doing the triage would do so, I have stopped double-checking that such work was being done but now, looking at the python-gnupg package, I noticed nothing was sent out to the maintainer, at least not with this list in CC. The maintainer and package are not in data/packages/lts-do-not-call.txt so I think they should have been contacted first. Am I missing something here? Did we change this practice, or is this an oversight? A. -- Arguing for surveillance because you have nothing to hide is no different than making the claim, "I don't care about freedom of speech because I have nothing to say." - Edward Snowden signature.asc Description: PGP signature
Re: [SECURITY] [DLA 1664-1] golang security update
On 2019-02-06 23:42:12, Chris Lamb wrote: > Hi Antoine, > >> all golang Debian packages are (as elsewhere) statically compiled >> and linked so we'd need to rebuild all the rdeps > > Hm. Can we avoid /all/ the rdeps? I mean, grep the rdeps for ones > that use this library? Yeah, that's what I was implying, sorry if that was unclear... I'm not actually sure how that works. I assume it's a bunch of binNMUs, but we first need to figure out which packages actually use that specific lib. Maintaining golang security update is really tricky.. :/ I wish we could just dynamically link everything in Debian, but I'm afraid that's heresy (even if technically possible, apparently) in Golang circles... a. -- The greatest crimes in the world are not committed by people breaking the rules but by people following the rules. It's people who follow orders that drop bombs and massacre villages. - Banksy
Re: [SECURITY] [DLA 1664-1] golang security update
On 2019-02-06 22:17:26, Chris Lamb wrote: > It was discovered that there was a denial of service vulnerability > or possibly even the ability to conduct private key recovery > attacks within in the elliptic curve cryptography handling in the > Go programming language libraries. Hello Chris! Have you given any thought to the impact this could have on the build-dependencies that might be affected by this vulnerability? As you probably know, all golang Debian packages are (as elsewhere) statically compiled and linked so we'd need to rebuild all the rdeps to have this properly fixed in the dependencies... A. -- Si Dieu est, l'homme est esclave ; or l'homme peut, doit être libre, donc Dieu n'existe pas. Et si Dieu existait, il faudrait s'en débarrasser! - Michel Bakounine
Re: buffer overflow vulnerability in netmask 2.3.12
On 2019-02-06 21:52:35, Guilhem Moulin wrote: > Hi anarcat, > > On Wed, 06 Feb 2019 at 14:13:23 -0500, Antoine Beaupré wrote: >> 4. issue a DLA when the package is accepted > > I wouldn't mind if you or another LTS team member were talking care of > this one :-) Alright, DLA coming right up! :) A. -- We should act only in such away that if everyone else acted as we do, we would accept the results. - Emmanuel Kant
Re: buffer overflow vulnerability in netmask 2.3.12
On 2019-02-06 01:59:58, Guilhem Moulin wrote: > Dear LTS team, Hi Guilhem! > A buffer overflow vulnerability was recently found in the netmask > package (a small utility that helps determining network masks): > > https://github.com/tlby/netmask/issues/3 > > The Security Team argued that the version in stretch (2.4.3-1) doesn't > warrant a DSA as the program is built with hardening options enabled > (thus turning the buffer overflow vulnerability into an harmless clash), > but that's not the case for the version in jessie (2.3.12), so I guess > it makes sense to upload a +deb8u1. Agreed. > I attach a debdiff with a trivial fix backported from 2.4.4, more > specifically the ‘errors.c’ part of > > > https://github.com/tlby/netmask/commit/29a9c239bd1008363f5b34ffd6c2cef906f3660c > > For convenience, you can also find the source package at > > dget -x https://people.debian.org/~guilhem/tmp/netmask_2.3.12+deb8u1.dsc > > Notes: > * I only started maintaining this package after jessie was frozen, but >the previous maintainer is no longer active and I thus took the >liberty to update the ‘Maintainer’ field in d/control accordingly. While this is usually a superfluous change, I think that in this case it makes sense so we know who to talk with the next time a problem happens (which will hopefully be never :). > * Before 2.4.2-1 the package was (incorrectly) native, so in this >jessie-security package I applied the fix directly to the upstream >source rather than going via a patch series. > * Upstream hasn't yet filed a CVE for this issue; I forwarded jmm's >instructions regarding this. Sorry, forwarded where? Did I miss something? Ideally, we would have at least one Debian-specific tracking number if we don't have a CVE. A bug in the BTS would do, for example. I'd be happy to do that administrativa if you wish. [...] The patch otherwise looks sound and should be uploaded. I believe the next step is to: 1. open a bug report in the BTS 2. mention it in the changelog 3. upload the package to security-master 4. issue a DLA when the package is accepted I'd be happy, like anyone else in the LTS team I'm sure, to take on any or all of those tasks, at your discretion. Cheers, A. -- Un éducateur dans l'âme ne prend rien au sérieux que par rapport à ses disciples -- soi-même non excepté. - Nietzsche, "Par delà le bien et le mal"
DLA-1654-1 libav missing?
Hi, It looks like no advisory was sent out for this upload. I noticed this while auditing the website for missing advisories. Yu'll be happy to know that with the current patchset, this is the only older advisory missing until the 2018 gap due to the mailing list crash. :) See also: https://salsa.debian.org/webmaster-team/webwml/merge_requests/53 A. On 2019-01-31 22:50:29, Mike Gabriel wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Format: 1.8 > Date: Mon, 21 Jan 2019 15:30:50 +0100 > Source: libav > Binary: libav-tools libav-dbg libav-doc libavutil54 libavcodec56 > libavdevice55 libavformat56 libavfilter5 libswscale3 libavutil-dev > libavcodec-dev libavdevice-dev libavformat-dev libavfilter-dev libswscale-dev > libavresample-dev libavresample2 libavcodec-extra-56 libavcodec-extra > Architecture: source all amd64 > Version: 6:11.12-1~deb8u5 > Distribution: jessie-security > Urgency: medium > Maintainer: Debian Multimedia Maintainers > > Changed-By: Mike Gabriel > Description: > libav-dbg - Debug symbols for Libav related packages > libav-doc - Documentation of the Libav API > libav-tools - Multimedia player, encoder and transcoder > libavcodec-dev - Development files for libavcodec > libavcodec-extra - Libav codec library (additional codecs meta-package) > libavcodec-extra-56 - Libav codec library (additional codecs) > libavcodec56 - Libav codec library > libavdevice-dev - Development files for libavdevice > libavdevice55 - Libav device handling library > libavfilter-dev - Development files for libavfilter > libavfilter5 - Libav video filtering library > libavformat-dev - Development files for libavformat > libavformat56 - Libav file format library > libavresample-dev - Development files for libavresample > libavresample2 - Libav audio resampling library > libavutil-dev - Development files for libavutil > libavutil54 - Libav utility library > libswscale-dev - Development files for libswscale > libswscale3 - Libav video scaling library > Changes: > libav (6:11.12-1~deb8u5) jessie-security; urgency=medium > . >* Non-maintainer upload by the LTS team.. >* CVE-2015-1207: avformat/mov: Fix integer overflow in > mov_read_udta_string(). >* CVE-2017-14169: In mxf_read_primer_pack() function, catch item_num > being negative, to avoid bypassing the check for a large value. >* CVE-2017-14223: avformat/asfdec: Fix DoS in asf_build_simple_index(). > Fix missing EOF check in loop. >* CVE-2017-7863: Bail out if trns was found before IHDR or IDAT in PNG > data. >* CVE-2014-8542: Add case for jv to avcodec_align_dimensions2(). >* CVE-2017-7865: Add case for interplay_video to > avcodec_align_dimensions2(). > Checksums-Sha1: > d1c670a1ede382a8c0a379895d99f2de6a9d8309 4023 libav_11.12-1~deb8u5.dsc > 4b74b8714868803c8b6b23df9b31e3c1d7e3a456 71392 > libav_11.12-1~deb8u5.debian.tar.xz > c364c438d26c1fe025166e7cbb541f54c7318496 18445106 > libav-doc_11.12-1~deb8u5_all.deb > 3862b02852aec371a5350796e07af48777ff4b39 66616 > libavcodec-extra_11.12-1~deb8u5_all.deb > 894d06bcacdf38396263eee1447d6576432f66da 474142 > libav-tools_11.12-1~deb8u5_amd64.deb > df4f9221da0209d855c8b43c4922f60fd66ba90a 21594462 > libav-dbg_11.12-1~deb8u5_amd64.deb > 210fc9597bc1f20b2b47d9f10b13bb0eec6b5aa2 131622 > libavutil54_11.12-1~deb8u5_amd64.deb > 8bbd6cb7be9e56840566b69514929d90df355428 3108618 > libavcodec56_11.12-1~deb8u5_amd64.deb > 9f492a7d32650e046c2e94e70c6eadc0e8c977a4 91496 > libavdevice55_11.12-1~deb8u5_amd64.deb > 66eac9eea9f2bc0640a1c123056cf39eb18ee707 586708 > libavformat56_11.12-1~deb8u5_amd64.deb > 4ef6c0f8076ef84482b5e44a1b6b2a89448a4df1 172670 > libavfilter5_11.12-1~deb8u5_amd64.deb > 08c94862cba93c2a25af004cd55f0f9ab9338788 145058 > libswscale3_11.12-1~deb8u5_amd64.deb > 375995325b23da7c3a6902d483527385c22151b2 193714 > libavutil-dev_11.12-1~deb8u5_amd64.deb > 1a782d1210d682704263ad81147994eed571273b 3431898 > libavcodec-dev_11.12-1~deb8u5_amd64.deb > 1f9411c19c4d4d1c4e3bfa85d4097455c998de8a 94544 > libavdevice-dev_11.12-1~deb8u5_amd64.deb > 8e04147d34c357e9de0321049235903b725b34bc 692202 > libavformat-dev_11.12-1~deb8u5_amd64.deb > 31887c8c10b450d83b2ffc2fa63a3d1d176f6818 203786 > libavfilter-dev_11.12-1~deb8u5_amd64.deb > b8261e35500052f89513f64f8fb9f1e498719273 157922 > libswscale-dev_11.12-1~deb8u5_amd64.deb > 419950f0408b0521c48847088b03aecf17c67d96 112968 > libavresample-dev_11.12-1~deb8u5_amd64.deb > 7d2e43e8e94af40eb99dd423a8943292a98beb39 104020 > libavresample2_11.12-1~deb8u5_amd64.deb > 9183cc4c375475f84d9b6cb45e8f6790b1264c46 3113166 > libavcodec-extra-56_11.12-1~deb8u5_amd64.deb > Checksums-Sha256: > 814e2e8337cf050ed55f62c1a8ec60934e027df64b84ed9bce9cf8a2c8816578 4023 > libav_11.12-1~deb8u5.dsc > b8c0bc197ef098a9bae1c9180ed3220606fe9c80f9b44ab9d98637417dae28ef 71392 > libav_11.12-1~deb8u5.debian.tar.xz > ab761dea136d2bf1171783c4e779edc6bb9c9a4dc058379ff23f77db0e5b05c5 18445106 > l
LTS report for January
Hello, Here's my report for January. ## sbuild regression My first stop this month was to notice a problem with sbuild from buster running on jessie chroots ([bug #920227][]). After discussions on IRC, where fellow Debian Developers basically fabricated me a patch on the fly, I sent [merge request #5][] which was promptly accepted and should be part of the next upload. [merge request #5]: https://salsa.debian.org/debian/sbuild/merge_requests/5 [bug #920227]: https://bugs.debian.org/920227 ## systemd I again worked a bit on systemd. I marked [CVE-2018-16866][] as not affecting jessie, because the vulnerable code was introduced in later versions. I backported fixes for [CVE-2018-16864][] and [CVE-2018-16865][] and published the resulting package as [DLA-1639-1][], after doing some smoke-testing. I still haven't gotten the courage to dig back in the large backport of `tmpfiles.c` required to fix [CVE-2018-6954][]. [CVE-2018-16864]: https://security-tracker.debian.org/tracker/CVE-2018-16864 [CVE-2018-16865]: https://security-tracker.debian.org/tracker/CVE-2018-16865 [CVE-2018-16866]: https://security-tracker.debian.org/tracker/CVE-2018-16866 [DLA-1639-1]: https://lists.debian.org/20190123042620.ga4...@curie.anarc.at [CVE-2018-6954]: https://security-tracker.debian.org/tracker/CVE-2018-6954 ## tiff review I did a quick review of the fix for [CVE-2018-19210][] [proposed upstream][] which seems to have brought upstream's attention back to the issue and finally merge the fix. [CVE-2018-19210]: https://security-tracker.debian.org/tracker/CVE-2018-19210 [proposed upstream]: https://gitlab.com/libtiff/libtiff/merge_requests/47 ## Enigmail EOL After [reflecting on the issue][] one last time, I decided to mark Enigmail as EOL in jessie, which involved an upload of debian-security-support to jessie ([DLA-1657-1][]), unstable and a [stable-pu][]. [stable-pu]: https://bugs.debian.org/921117 [DLA-1657-1]: https://lists.debian.org/87sgx72z6a@curie.anarc.at [reflecting on the issue]: https://lists.debian.org/87tvi0cw99@curie.anarc.at ## DLA / website work I worked again on fixing the LTS workflow with the DLAs on the main website. Reminder: hundreds of DLAs are missing from the website ([bug #859122][]) and we need to figure out a way to automate the import of newer ones ([bug #859123][]). The details of my work are in [this post][] but basically, I readded a bunch more DLAs to the MR and got some good feedback from the www team (in [MR #47][]). There's still some work to be done on the DLA parser, although I have merged my own improvements ([MR #46][]) as I felt they had been sitting for review long enough. Next step is to deal with noise like PGP signatures correctly and thoroughly review the proposed changes. While I was in the webmaster's backyard, I tried to help with a few things by merging a [LTS errata][] and a [paypal integration note][] although the latter ended up being a mistake that was reverted. I also rejected some issues ([MR #13][], [MR #15][]) during a quick triage. [bug #859122]: https://bugs.debian.org/859122 [bug #859123]: https://bugs.debian.org/859123 [this post]: https://lists.debian.org/87o97v2vt1@curie.anarc.at [MR #47]: https://salsa.debian.org/webmaster-team/webwml/merge_requests/47 [MR #46]: https://salsa.debian.org/webmaster-team/webwml/merge_requests/46> [LTS errata]: https://salsa.debian.org/webmaster-team/webwml/merge_requests/40 [paypal integration note]: https://salsa.debian.org/webmaster-team/webwml/merge_requests/39 [MR #15]: https://salsa.debian.org/webmaster-team/webwml/merge_requests/15 [MR #13]: https://salsa.debian.org/webmaster-team/webwml/merge_requests/13 ## phpMyAdmin review After reading this [email from Lucas Kanashiro][], I [reviewed][] [CVE-2018-19968][] and reviewed and tested [CVE-2018-19970][]. [reviewed]: https://lists.debian.org/87imy32tlu@curie.anarc.at [email from Lucas Kanashiro]: https://lists.debian.org/c2fbedd3-436c-0497-c987-69fa5b213...@riseup.net [CVE-2018-19970]: https://security-tracker.debian.org/tracker/CVE-2018-19970 [CVE-2018-19968]: https://security-tracker.debian.org/tracker/CVE-2018-19968 -- Non qui parum habet, sed qui plus cupit, pauper est. It is not the man who has too little, but the man who craves more, that is poor.- Lucius Annaeus Seneca (65 AD) signature.asc Description: PGP signature
Re: DLAs not arriving at my mailbox and I think it may be a general issue
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). Cheers, A. -- Be the change you want to see happen. - Arleen Lorrance, 1974
Re: Review and testing phpmyadmin for Jessie LTS
Hi, I've reviewed both patches and they look sane. I did some smoke tests on the package (installed it and mariadb in a VM) and it seems to run okay. I also did an naive attempt at exploiting CVE-2018-19970 but couldn't succeed, which can either mean I failed or the flaw is fixed. :) Good job, A. On 2019-01-29 15:27:59, Lucas Kanashiro wrote: > Hugo, > > I just uploaded a new package fixing the issue that you pointed out here > again: https://people.debian.org/~kanashiro/jessie_lts/phpmyadmin/ > > I didn't perform any new testing yet, I want to do it soon. But if you > could have a try again it would be great. > > Cheers. > > On 1/29/19 11:37 AM, Hugo Lefeuvre wrote: >> Hi Lucas, >> >>> Great, sorry for being a victim of my lack of attention... I've never >>> used phpmyadmin (that's why I requested some testing) and my local tests >>> were so basic that they didn't catch this issue. Shame on me. >> That's > >> fine, main thing is issues have been found before upload :) >> >>> I'll fix it and perform some tests. Thanks for the review and the time >>> that you spent on this. >> I am available for testing the updated package if needed. >> >> cheers, >> Hugo >> > -- > Lucas Kanashiro -- Drowning people Sometimes die Fighting their rescuers. - Octavia Butler
Re: automating process for publishing DLAs on the website
I'm looking at the update process for DLAs on the main website again. In #859122, I've mentioned that I have, again, updated the MR to include all DLAs up to DLA-1657-1. The www team folks tell me they will review that this weekend. But that mass-import process is kind of clunky: every time I need to download the entire archive, extract it, parse every email, and add the diff. It's slow and error prone and not automated, of course. So I'm bringing back the topic of how we should automate this. If I remember correctly, the current proposal is to add this as part of the workflow for LTS developers: when you send the announcement on the list, you also send a merge request on the website. This would get reviewed and merged by another LTS developer with access to the webwml repository: https://salsa.debian.org/webmaster-team/webwml/project_members At least me and Holger have those accesses for now, and I would suggest people who do regular frontdesk work could make sure those MR are reviewed and merged in a timely manner as well. Would that work for everyone here? If so, we can *already* start with that process, which would actually look like this. One time setup: git clone https://salsa.debian.org/webmaster-team/webwml cd webwml salsa fork Each time there's a new DLA: ./bin/gen-DLA --save $CHANGES # correctly claim the DLA $EDITOR DLA--Y # make sure the text is okay, like you normally # do before the email gets sent mutt -H DLA--Y # send the email cd ~/src/webwml/english/security git checkout -b DLA--Y ./parse-dla.pl ~-/DLA--Y git add 2019/DLA-XXX-Y* $EDITOR 2019/DLA--Y* # make sure everything looks good git add 2019/DLA-XXX-Y* git commit -m'DLA--Y advisory' git push -u origin salsa mr (Note: that "salsa" command is a new one shipped with devscripts. I only read the manpage and didn't actually test that. :) Unfortunately, once the MR is created, there's no magic command to merge it for reviewers... Seems like this needs to be done through the web interface.) I'd be happy if someone sat down and actually tested that procedure. The alternative, of course, is to setup "something" that would automatically parse emails to debian-lts-announce@l.d.o but I suspect that could be much more brittle than a manual operation like the above, even if it means slightly more work. Thank you for your attention. A. -- Hard times are coming when we will be wanting the voices of writers who can see alternatives to how we live now and can see through our fear-stricken society and its obsessive technologies to other ways of being, and even imagine some real grounds for hope. We will need writers who can remember freedom. Poets, visionaries—the realists of a larger reality. - Ursula Le Guin
Re: about 500 DLAs missing from the website
On 2018-12-19 18:05:36, Antoine Beaupré wrote: > The DLAs are visible here: > > https://www-staging.debian.org/security/2018/dla-1580 > > One thing that's unclear is how the entries get added to the main list > in: > > https://www-staging.debian.org/security/2018/ > > That still needs to be cleared up. That's actually in the webwml code, I opened a MR to add those: https://salsa.debian.org/webmaster-team/webwml/merge_requests/50 > In the meantime, I did do a mass > import here: > > https://salsa.debian.org/webmaster-team/webwml/merge_requests/47 ... and I just updated that with the latest, up until DLA-1657-1. A. -- It will be a great day when our schools get all the money they need and the air force has to hold a bake sale to buy a bomber. - Unknown
HEADS UP: enigmail to be EOL'd by the end of week
On 2019-01-22 15:21:19, Daniel Kahn Gillmor wrote: > On Tue 2019-01-22 14:44:50 -0500, Antoine Beaupré wrote: >> I'm not sure we should remove *both* enigmail and thunderbird from >> jessie. I understand there are problems with the a.m.o version, but then >> that's somewhat outside of scope of LTS. It would seem rather unfair for >> users of thunderbird that do *not* use enigmail to have their favorite >> email client yanked away from them because a third-party plugin fails to >> be maintainer correctly. >> >> Right now I'm leaning towards completely dropping support from Enigmail >> in jessie, since the changes required are too far ranging to be >> comfortable. > > I've yet to hear a specific concern about a known failure that derives > from the backporting work that anarcat did. > > I know of several concrete failures that will result from users of > Jessie pulling enigmail from a.m.o. > > telling jessie users that they should pull from a.m.o. is effectively > doing them a disservice, if they think they're being supported. > > If i was responsible for maintaining jessie, i'd prefer to go the route > of the backported fixes, but i don't have the capacity to spend a lot of > time on jessie itself, so i guess my preferences should be weighed > accordingly. So I understand where you're coming from. As you suggested, however, I feel I should give more weight to my LTS and security team members in this specific case. If this was just enigmail and gpg, I would definitely defer to you as you are a core maintainer of those packages. The update touches much more than the gpg toolchain. I don't feel comfortable spending more time testing the repercussions of the change throughout the ever expending dependencies of gcrypt. So I will look at sending a EOL announcement on the mailing list soon, and do the required debian-security-support changes as well, unless someone objects by the end of the week. It's too bad all this work will get lost, but I don't have the energy to push this one against the tide anymore. And if someone would or could have picked it up, they would have done so already. The best course, at this point, seems to let this die already. A. -- The greatest crimes in the world are not committed by people breaking the rules but by people following the rules. It's people who follow orders that drop bombs and massacre villages. - Banksy
Re: proposed removal of Enigmail from jessie/LTS
On 2018-12-20 14:30:49, Daniel Kahn Gillmor wrote: > fwiw, i agree with jmm that encouraging users to upgrade to stable is > the best outcome here. The question is, what are we doing to the folks > who (for whatever reason) can't make that switch. > > On Thu 2018-12-20 17:01:30 +0100, Moritz Mühlenhoff wrote: >> If suddenly all kinds of core libraries are getting updated in jessie >> (with minimal testing) > > we're not talking about "all kinds of core libraries" -- we're talking > about a very selected subset. And i don't think we're talking about > "minimal testing", there has been a reasonable amount of testing. I > think we ought to consider this specific case, rather than trying to > make a systematized rule. > >> EOLing enigmail seems the only sensible option by far. > > the main issue with EOLing enigmail is that users will (instead of > upgrading to stable) typically just use the version from > addons.mozilla.org, which has both non-DFSG-free issues and > significantly scary behavior (downloading and silently executing > binaries from the web on the user's behalf). > > If we're EOLing thunderbird on jessie entirely, that'd be one thing (and > i'd be ok with it). But EOLing enigmail on its own sounds like a route > to trouble for enigmail users on jessie. So looking back at this problem again... I'm not sure we should remove *both* enigmail and thunderbird from jessie. I understand there are problems with the a.m.o version, but then that's somewhat outside of scope of LTS. It would seem rather unfair for users of thunderbird that do *not* use enigmail to have their favorite email client yanked away from them because a third-party plugin fails to be maintainer correctly. Right now I'm leaning towards completely dropping support from Enigmail in jessie, since the changes required are too far ranging to be comfortable. But I could be convinced otherwise. A. -- Il n'existe aucune limite sacrée ou non à l'action de l'homme dans l'univers. Depuis nos origines nous avons le choix: être aveuglé par la vérité ou coudre nos paupières. - [no one is innocent]
Re: limits of automatic unclaiming (Re: pdns/pdns-recursor)
On 2018-12-27 14:16:22, Holger Levsen wrote: > Hi Abhijith, Antoine, > > I just ran "./bin/review-update-needed --lts --unclaim 1814400 --exclude > linux linux-4.9" today and it unclaimed pdns/pdns-recursor as the last > NOTE entries were more than 3 weeks ago. However Abhijith wrote here: > > On Sat, Dec 22, 2018 at 01:02:06PM +0530, Abhijith PA wrote: >> I am currently working on pdns[1] and pdns-recursor's[2] security issues >> and which are marked as no-DSA, postponed. Last month I picked it up as >> I had some time remaining. Upstream patch is available for the remaining >> issues(CVE-2018-10851, CVE-2018-14644). Both patches contain C++11 >> specific code and I was only able to port CVE-2018-14644. In >> CVE-2018-10851 I used 'boost' library's smart pointers to deal with the >> default C++11 smart pointers, but I am not quite there. I was wondering >> whether anyone here can _help_ me with it. I don't want to spend anymore > > Abhijith, thanks for this update! Just please also update the notes for > these packages in data/dla-needed.txt. > > Antoine, this is an example were automatic unclaim might be problematic, > as it would have unclaimed pdns/pdns-recursor which is not ideal. (For > now, just ment as a data point.) I'm not sure it would be that problematic. I think Abhijith could (should?) have posted a note in dla-needed.txt summarizing this situation or adding a pointer to the above email. The idea, anyways, is that worst case the issue gets unclaimed and reclaimed by someone else. In the above case, Abhijith specifically identified that as a *desirable* outcome, so I'm not sure it's really a problem. Personally, I believe the general case of unexpected unclaims will be the package will be unclaimed and *not* claimed by anyone else. At least that's my experience of unclaiming "hard" packages that I couldn't finish within a month. A. -- Non qui parum habet, sed qui plus cupit, pauper est. It is not the man who has too little, but the man who craves more, that is poor.- Lucius Annaeus Seneca (65 AD)
Re: monthly report
[Ugh. Sorry about that last email, the markup was terrible - I copy-pasted from Emacs' markdown mode which ellipsises links... Here's a better formatted one.] ## Enigmail / GnuPG 2.1 backport I've spent a significant amount of time working on the Enigmail backport for a third consecutive month. I first [published][] a straightforward backport of GnuPG 2.1 depending on the libraries available in jessie-backports last month, but then I actually [rebuilt the dependencies as well][] and sent a "HEADS UP" to the mailing list, which finally got peoples' attention. [rebuilt the dependencies as well]: https://lists.debian.org/87zht94219@curie.anarc.at [published]: https://lists.debian.org/87r2fqnja0@curie.anarc.at There are many changes bundled in that possible update: GnuPG actually depends on about half a dozen other libraries, mostly specific to GnuPG, but in some cases used by third party software as well. The most problematic one is [libgcrypt20][] which Emilio Pozuelo Monfort [said][] included tens of thousands of lines of change. So even though I tested the change against cryptsetup, gpgme, libotr, mutt and Enigmail itself, there are concerns that other dependencies that merit more testing as well. [libgcrypt20]: https://tracker.debian.org/libgcrypt20 [said]: https://lists.debian.org/6a8835ce-f54d-faa6-2689-aeb91b1b6...@debian.org This caused many to raise the idea of aborting the work and simply marking Enigmail as unsupported in jessie. But Daniel Kahn Gillmor [suggested][] this should also imply removing Thunderbird itself from jessie, as simply removing Enigmail will force people to use the binaries from Mozilla's add-ons service. Gillmor [explained][] those builds include a OpenPGP.js implementation of dubious origin, which is especially problematic considering it deals with sensitive private key material. [explained]: https://lists.debian.org/878t0mzlv2@fifthhorseman.net [suggested]: https://lists.debian.org/87pntxxg6h@fifthhorseman.net It's unclear which way this will go next. I'm taking a break of this issue and hope others will be able to test the packges. If we keep on working on Enigmail, the next step will be to re-enable the `dbg` packages that were removed in the stretch updates, use dh-autoreconf correctly, remove some `mingw` pacakges I forgot and [test gcrypt like crazy][] ([especially the 1.7 update][]). We'd also update to the latest Enigmail, as it fixes issues that forced the Tails project to [disable autocrypt][] because of [weird interactions][] that make it send cleartext (instead of encrypted) mail in some cases. [weird interactions]: https://redmine.tails.boum.org/code/issues/15923 [disable autocrypt]: https://redmine.tails.boum.org/code/issues/16186 [especially the 1.7 update]: https://lists.debian.org/20181220130018.ga5...@argenau.bebt.de [test gcrypt like crazy]: https://lists.debian.org/1c1ca626-de3c-1f72-3c95-e280c1bdf...@debian.org ## Automatic unclaimer My [previous report][] yielded an [interesting discussion][] around my work on the security tracker, specifically the "automatic unclaimer" designed to unassign issues that are idle for too long. Holger Levsen, with his new coordinator hat, tested the program and found many bugs and missing features, which I was happy to implement. After many patches and back and forth, it seems the program is working well, although it's ran by hand by the coordinator. [interesting discussion]: https://lists.debian.org/debian-lts/2018/11/msg00097.html [previous report]: https://lists.debian.org/debian-lts/2018/11/msg00090.html ## DLA website publication I took a look at various issues surrounding the publication of LTS advisories on the main debian.org website. While normal security advisories are regularly published on [debian.org/security][] [about 500+ DLAs are missing from the website][], mainly because [DLAs are not automatically imported][]. [DLAs are not automatically imported]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859123 [about 500+ DLAs are missing from the website]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859122 [debian.org/security]: https://www.debian.org/security/ As it turns out, there is a script called `parse-dla.pl` that is designed to handle those entries but for some reason, they are not imported anymore. So I got to work to import the backlog and make sure new entries are properly imported. [Various fixes for parse-dla.pl][] were necessary to properly parse messages both from the templates generated by `gen-DLA` and the existing archives correctly. then I tested the result with two existing advisories, which resulted in two MR on the webml repo: [add data for DLA-1561][] and [add dla-1580 advisory][]. I requested and was granted access to the repo, and eventually merged my own MRs after a review from Levsen. [add dla-1580 advisory]: https://salsa.debian.org/webmaster-team/webwml/merge_requests/42 [add data for DLA-1561]: https://salsa.debian.org/webmaster-tea
monthly report
Hi! This is my monthly report, published on the mailing list as I haven't found time to do my personal report on my blog in over a month now... ## Enigmail / GnuPG 2.1 backport I've spent a significant amount of time working on the Enigmail backport for a third consecutive month. I first [published](https://lists.debian.org/87r2fqnja0@curie.anarc.at) a straightforward backport of GnuPG 2.1 depending on the libraries available in jessie-backports last month, but then I actually [rebuilt the dependencies as well](https://lists.debian.org/87zht94219@curie.anarc.at) and sent a "HEADS UP" to the mailing list, which finally got peoples' attention. There are many changes bundled in that possible update: GnuPG actually depends on about half a dozen other libraries, mostly specific to GnuPG, but in some cases used by third party software as well. The most problematic one is [[!debpkg libgcrypt20]] which Emilio Pozuelo Monfort [said](https://lists.debian.org/6a8835ce-f54d-faa6-2689-aeb91b1b6...@debian.org) included tens of thousands of lines of change. So even though I tested the change against cryptsetup, gpgme, libotr, mutt and Enigmail itself, there are concerns that other dependencies that merit more testing as well. This caused many to raise the idea of aborting the work and simply marking Enigmail as unsupported in jessie. But Daniel Kahn Gillmor [suggested](https://lists.debian.org/87pntxxg6h@fifthhorseman.net) this should also imply removing Thunderbird itself from jessie, as simply removing Enigmail will force people to use the binaries from Mozilla's add-ons service. Gillmor [explained](https://lists.debian.org/878t0mzlv2@fifthhorseman.net) those builds include a OpenPGP.js implementation of dubious origin, which is especially problematic considering it deals with sensitive private key material. It's unclear which way this will go next. I'm taking a break of this issue and hope others will be able to test the packges. If we keep on working on Enigmail, the next step will be to re-enable the `dbg` packages that were removed in the stretch updates, use dh-autoreconf correctly, remove some `mingw` pacakges I forgot and [test gcrypt like crazy](https://lists.debian.org/1c1ca626-de3c-1f72-3c95-e280c1bdf...@debian.org) ([especially the 1.7 update](https://lists.debian.org/20181220130018.ga5...@argenau.bebt.de)). We'd also update to the latest Enigmail, as it fixes issues that forced the Tails project to [disable autocrypt](https://redmine.tails.boum.org/code/issues/16186) because of [weird interactions](https://redmine.tails.boum.org/code/issues/15923) that make it send cleartext (instead of encrypted) mail in some cases. ## Automatic unclaimer My [previous report][] yielded an [interesting discussion](https://lists.debian.org/debian-lts/2018/11/msg00097.html) around my work on the security tracker, specifically the "automatic unclaimer" designed to unassign issues that are idle for too long. Holger Levsen, with his new coordinator hat, tested the program and found many bugs and missing features, which I was happy to implement. After many patches and back and forth, it seems the program is working well, although it's ran by hand by the coordinator. [previous report]: https://lists.debian.org/debian-lts/2018/11/msg00090.html ## DLA website publication I took a look at various issues surrounding the publication of LTS advisories on the main debian.org website. While normal security advisories are regularly published on [debian.org/security](https://www.debian.org/security/) [about 500+ DLAs are missing from the website](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859122), mainly because [DLAs are not automatically imported](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859123). As it turns out, there is a script called `parse-dla.pl` that is designed to handle those entries but for some reason, they are not imported anymore. So I got to work to import the backlog and make sure new entries are properly imported. [Various fixes for parse-dla.pl](https://salsa.debian.org/webmaster-team/webwml/merge_requests/43) were necessary to properly parse messages both from the templates generated by `gen-DLA` and the existing archives correctly. then I tested the result with two existing advisories, which resulted in two MR on the webml repo: [add data for DLA-1561](https://salsa.debian.org/webmaster-team/webwml/merge_requests/41) and [add dla-1580 advisory](https://salsa.debian.org/webmaster-team/webwml/merge_requests/42). I requested and was granted access to the repo, and eventually merged my own MRs after a review from Levsen. I eventually used the following procedure to test importing the entire archive: rsync -vPa master.debian.org:/home/debian/lists/debian-lts-announce . cd debian-lts-announce xz -d \*.xz cat \* > ../giant.mbox mbox2maildir ../giant.mbox debian-lts-announce.d for mail in debian-lts-announce.d/cur/\*; do ~/src/se
Re: proposed removal of Enigmail from jessie/LTS
On 2018-12-20 14:30:49, Daniel Kahn Gillmor wrote: > fwiw, i agree with jmm that encouraging users to upgrade to stable is > the best outcome here. The question is, what are we doing to the folks > who (for whatever reason) can't make that switch. > > On Thu 2018-12-20 17:01:30 +0100, Moritz Mühlenhoff wrote: >> If suddenly all kinds of core libraries are getting updated in jessie >> (with minimal testing) > > we're not talking about "all kinds of core libraries" -- we're talking > about a very selected subset. And i don't think we're talking about > "minimal testing", there has been a reasonable amount of testing. I > think we ought to consider this specific case, rather than trying to > make a systematized rule. > >> EOLing enigmail seems the only sensible option by far. > > the main issue with EOLing enigmail is that users will (instead of > upgrading to stable) typically just use the version from > addons.mozilla.org, which has both non-DFSG-free issues and > significantly scary behavior (downloading and silently executing > binaries from the web on the user's behalf). > > If we're EOLing thunderbird on jessie entirely, that'd be one thing (and > i'd be ok with it). But EOLing enigmail on its own sounds like a route > to trouble for enigmail users on jessie. Thanks both of you for your feedback. I'm running out of time until the holidays so I will personally let that one rest until January. The packages are on people.d.o and can be tested by anyone. I think it would be very useful if people would pursue that. Alternatively, we can just drop support for Enigmail in jessie, as I proposed in September. It just feels it's too bad to have wasted all that time only to give up when we're so close to the goal, only because of libgcrypt. But, as Emilio said, we coudln't have forseen those difficulties back then so maybe it's fair to just give up at this point. I would be worried about our users however... Have a nice holiday season, or congress for those of you with that privilege. ;) A. -- The price of reliability is the pursuit of the utmost simplicity. - C.A.R. Hoare
Re: automating process for publishing DLAs on the website
On 2018-12-19 18:05:36, Antoine Beaupré wrote: > On 2018-12-19 11:09:10, Antoine Beaupré wrote: >> On 2018-12-19 14:58:29, Holger Levsen wrote: >>> On Wed, Dec 19, 2018 at 09:52:19AM -0500, Antoine Beaupré wrote: >>>> > I also note #859122 is not marked 'patch'. >>>> fixed. >>> >>> :) >>> >>>> >> I've requested access as an individual, for what that's worth. >>>> > you were given access a week ago, too. \o/ >>>> yup. I guess I could just merge my own patches now... or do you want to >>>> review them and do that instead, so we can get at least a second pair of >>>> eyes on them? >>> >>> I just briefly reviewed them (not being a debian-www expert) and they >>> a.) looked good and b.) only affect our areas, so I do think you should >>> merge them. >> >> i merged both patches, but it doesn't look like the change showed up on >> the main website yet: >> >> https://www.debian.org/security/2018/ >> >> ... doesn't list any DLA, and those are both 404s: >> >> https://www.debian.org/security/2018/dla-1580 >> https://www.debian.org/security/2018/dla-1561 > > This is actually processed every few hours, not directly after the CI > runs. > > The DLAs are visible here: > > https://www-staging.debian.org/security/2018/dla-1580 > > One thing that's unclear is how the entries get added to the main list > in: > > https://www-staging.debian.org/security/2018/ > > That still needs to be cleared up. In the meantime, I did do a mass > import here: > > https://salsa.debian.org/webmaster-team/webwml/merge_requests/47 Sigh. I forgot to add that one issue that came up is duplicates: even though the security tracker enforces unique DLA identifiers fairly well, human error still creeps in and leads to duplicate DLA identifiers in the wild. This will make automation harder: the current parser croaks out on duplicate identifiers (and rightly so). I guess we can just punt that back to the humans: they just need to issue a new advisory with the correct identifier. The problem is this is first come, first serve: if DLA X is claimed by alice and bob comes in and publishes DLA X before alice has time to send the mail, DLA X is on the website and can't be reverted by the script and will need manual correction. I am worried this will be forgetten in the future... A. -- The difference between a democracy and a dictatorship is that in a democracy you vote first and take orders later; in a dictatorship you don't have to waste your time voting. - Charles Bukowski
Re: automating process for publishing DLAs on the website
On 2018-12-19 11:09:10, Antoine Beaupré wrote: > On 2018-12-19 14:58:29, Holger Levsen wrote: >> On Wed, Dec 19, 2018 at 09:52:19AM -0500, Antoine Beaupré wrote: >>> > I also note #859122 is not marked 'patch'. >>> fixed. >> >> :) >> >>> >> I've requested access as an individual, for what that's worth. >>> > you were given access a week ago, too. \o/ >>> yup. I guess I could just merge my own patches now... or do you want to >>> review them and do that instead, so we can get at least a second pair of >>> eyes on them? >> >> I just briefly reviewed them (not being a debian-www expert) and they >> a.) looked good and b.) only affect our areas, so I do think you should >> merge them. > > i merged both patches, but it doesn't look like the change showed up on > the main website yet: > > https://www.debian.org/security/2018/ > > ... doesn't list any DLA, and those are both 404s: > > https://www.debian.org/security/2018/dla-1580 > https://www.debian.org/security/2018/dla-1561 This is actually processed every few hours, not directly after the CI runs. The DLAs are visible here: https://www-staging.debian.org/security/2018/dla-1580 One thing that's unclear is how the entries get added to the main list in: https://www-staging.debian.org/security/2018/ That still needs to be cleared up. In the meantime, I did do a mass import here: https://salsa.debian.org/webmaster-team/webwml/merge_requests/47 A. -- Le péché est né avant la vertu, comme le moteur avant le frein. - Jean-Paul Sartre
Re: proposed removal of Enigmail from jessie/LTS
On 2018-12-19 21:22:21, Emilio Pozuelo Monfort wrote: > Hi Antoine, > > On 19/12/2018 18:25, Antoine Beaupré wrote: >> On 2018-12-19 17:03:26, Holger Levsen wrote: >>> On Wed, Dec 19, 2018 at 11:40:07AM -0500, Antoine Beaupré wrote: >>> [...] >>> I've now also re-read this thread (for the 2nd time today..) and first >>> I'd like to notice that all the concerns were only brought up in the >>> last week, so it was definitly right from you to work on this for those >>> months. Second, it now reads to me as if Emilio changed his mind after >>> expressing concerns on Dec 14th, he indeed replied much more favorably >>> on the 18th. >> >> Thanks for your message, I'm relieved and happy to get support from >> you. :) > > I'm sorry if my comments caused your frustration. I think you have done an > amazing job getting all this work done. I just think we need to try and > balance > the goal of supporting all packages that we can, versus the risk or causing > regressions in important stuff. You're right. Sorry I might have overreacted - I am going through some intense family issues right now and I might be a little jittery. :) >>> I mostly worried that you didnt test all dependent packages and that we >>> essentially might break those when trying to support a package no >>> customer has expressed need for. But then I also suppose such breakage >>> could be fixed... >> >> So I was mostly concerned about libgcrypt dependencies, and in >> particular cryptsetup, and smoke tests seems to go through okay >> there, for what that's worth... > > cryptsetup is definitely one of the main rdeps. Also libgcrypt20 is used by > systemd, ntfs-3g. There's also libssh, which is used by e.g. qemu, php-ssh2, > libcurl... > > That doesn't mean we can't upgrade it. It just means it's an important package > and the risk is higher due to its wide use and because of the extensive > changes. > Just need to be extra careful. Right. >>> and now we are back to square one :/ >> >> Not really. We're actually at square N-1, we just need to do that one >> final jump to get in the "let's actually support that newer version" >> game. :p >> >> Should we pursue this? Are there any other packages that should be >> tested? >> >> Would love other people's opinion as well... > > Maybe some of the other rdeps. libssh test suite (if it has one), systemd... > However in the end it will come down to whether you feel confident to push > that > out or think it's better to stay put. > > Whatever you decide, I'll do my best to help in any way I can. That's great! :) Unfortunately I'm running out of time this month - I have a measly 2-3h left this month and holidays are coming up so I don't know if I'll be able to complete this before the new year. A. -- Celui qui ne connaît pas l'histoire est condamné à la revivre. - Karl Marx
Re: proposed removal of Enigmail from jessie/LTS
On 2018-12-19 17:03:26, Holger Levsen wrote: > On Wed, Dec 19, 2018 at 11:40:07AM -0500, Antoine Beaupré wrote: > [...] > I've now also re-read this thread (for the 2nd time today..) and first > I'd like to notice that all the concerns were only brought up in the > last week, so it was definitly right from you to work on this for those > months. Second, it now reads to me as if Emilio changed his mind after > expressing concerns on Dec 14th, he indeed replied much more favorably > on the 18th. Thanks for your message, I'm relieved and happy to get support from you. :) > I mostly worried that you didnt test all dependent packages and that we > essentially might break those when trying to support a package no > customer has expressed need for. But then I also suppose such breakage > could be fixed... So I was mostly concerned about libgcrypt dependencies, and in particular cryptsetup, and smoke tests seems to go through okay there, for what that's worth... > and now we are back to square one :/ Not really. We're actually at square N-1, we just need to do that one final jump to get in the "let's actually support that newer version" game. :p Should we pursue this? Are there any other packages that should be tested? Would love other people's opinion as well... A. -- Pour marcher au pas d'une musique militaire, il n'y a pas besoin de cerveau, une moelle épinière suffit. - Albert Einstein
Re: HEADS UP: upcoming change to libgcrypt and other gnupg libraries for Enigmail backport
On 2018-12-18 14:34:06, Emilio Pozuelo Monfort wrote: [...] > Looking at a jessie -> jessie-new diff, I see that several -dbg packages are > gone in your backports. Yes. That's because they were switched to dbgsym in stretch, but that mecanism wasn't supported in jessie. I did a "fast" backport which meant just dropping those, but I could possibly re-create the -dbg packages for jessie-security, especially considering we might trigger bugs and regressions which could really use dbg/gdb support. > There are some mingw builds as well, which in some cases > don't seemto be installed, but e.g. libgpg-error actually adds a mingw > package. > I would remove all that stuff. Hmm... I *thought* I explicitely removed all that stuff, but i'll make sure to remove that one as well, thanks for the catch! > The npth diff is pretty trivial, basically comes down to this: > > src/npth.c | 132 Neat, I'll explicitely review that one then. > libassuan is a bit larger, but not too bad: > > $ diff libassuan-2.*/src/ | diffstat | tail -1 > 26 files changed, 1492 insertions(+), 510 deletions(-) > > (some of that is Makefile.in) Probably worth reviewing as well... > libgpg-error has some autogenerated stuff, ignoring that it's mostly this: > > estream.c| 1456 > +-- ... and same. > libgcrypt is a bit more worrying, even after dropping most of the noise: > > $ diff libgcrypt20-1.*/ | filterdiff -x '*.pc/*' -x '*/debian/*' -x > '*/tests/*' > | diffstat | tail -1 > 263 files changed, 51927 insertions(+), 14888 deletions(-) Yeah, that's my concern as well. Daniel, what do you think of that diff? Is that something we can reasonably review? How much can we expect stability in that upgrade? I know you stated before general principles of gpg vs lib / API stability, but I'd be curious to hear your thoughts on gcrypt, in this specific case. > FWIW I see that Ubuntu added OpenPGP.js back, and is using gnupg 2.0.x in > trusty. We ruled that out because supporting gnupg 2.0.x is unfeasible or > because we are missing some dependencies for OpenGPG.js ? Can't we just use > the > bundled code inside enigmail? Sorry if these questions have already been > answered. I have looked at the various long threads but wasn't sure. Yeah, I went down that rabbit hole... three months ago now! I documented my work in bug #787774. It's a complicated set of nesting dependencies, and many packages would first need to cross NEW in unstable (let alone stretch / jessie) before this lands in Debian. A summary of the situation is here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787774#49 I made a wiki page, back then, detailing all those dependencies. I am just re-running the script again to get an accurate picture: https://wiki.debian.org/Javascript/Nodejs/Tasks/openpgp That's all stuff in unstable, mind you. All that would need to trickle down in jessie somehow, and that includes npm/nodejs, which I am not sure are in good health in jessie in the first place. A. -- During times of universal deceit, telling the truth becomes a revolutionary act. - Georges Orwell
proposed removal of Enigmail from jessie/LTS
On 2018-12-19 16:21:46, Holger Levsen wrote: > Hi Antoine, dkg, > > On Sat, Dec 15, 2018 at 01:09:39PM +0100, Moritz Mühlenhoff wrote: >> On Fri, Dec 14, 2018 at 09:08:42AM +0100, Emilio Pozuelo Monfort wrote: >> > However given the impact of these library updates, I was wondering >> > if we have considered to just mark enigmail as EOL in jessie? Obviously if >> > we >> > can keep supporting stuff we should do that, but as you say these library >> > updates affect important unrelated rdeps so we need to weigh that. >> +1 > > I've read this thread multiple times now and came to conclude that > Moritz and Emilio are probably right here, also because - afaics - noone > besides you two have tested the packages on > https://people.debian.org/~anarcat/debian/jessie-lts/ and also mostly > concerning whether they fix enigmail, not so much for subtile breakage > in other parts. (Or did I miss something?) > > Then I also looked at the packages LTS customers (=sponsors) are using > and noted neither enigmail nor libgcrypt20 are among those, so while I > agree breaking/not fixing/declaring EOL of enigmail will be sad for our > jessie users, I also think that most web users are using modern desktops > now (though of course those still on jessie are bitten) and that keeping > jessie stable should have highest priority. > > Of course, more tests could probably convince me again in the other > direction.. ;) So I appreciate finally getting feedback on this proposal, but I'll just note that I've been personnally working on this project for over three months now, and it's the first time the proposal to remove Enigmail from jessie has been explicitely supported instead of the gnupg backport. That is, as far as I can remember and find through archive searches. I've brought up the topic of how to deal with breakage on Enigmail numerous times on this forum. The first thread starts here, in September: https://lists.debian.org/871s9fps8e@curie.anarc.at I even explicitely proposed to remove enigmail from jessie here: https://lists.debian.org/87pnwzngcy@curie.anarc.at There was no explicit support for that idea and limited feedback on the other proposals I brought up. After helping dkg with the stretch package, thinking that would would eventually benefit jessie as well (or ultimately even stretch-LTS), I waited another month and brought up the proposals again: https://lists.debian.org/87pnvra144@curie.anarc.at Both Emilio and Daniel supported the idea of pushing the GnuPG 2.1 backport. So I did that and spent most of my LTS time for december working on the GnuPG 2.1 upload. I was just about to finalize the upload, based on Emilio's review of the patchset, when I read your message. Now I'm at a loss at what to do with this project. Obviously, it would be easy to upload a new debian-security-support package to declare Enigmail dead. But it would have been a much more efficient use of our time if we would have decided that back in september when I first brought up the idea. I find this situation rather frustrating, to say the least. I understand people don't always have time to read all messages and respond promptly to proposals, but I think I've given that one plenty of time, so it's a little difficult to just drop everything now, after so much work has been done to finalize that backport. A. -- Le pouvoir n'est pas à conquérir, il est à détruire - Jean-François Brient, de la servitude moderne
Re: automating process for publishing DLAs on the website
On 2018-12-19 14:58:29, Holger Levsen wrote: > On Wed, Dec 19, 2018 at 09:52:19AM -0500, Antoine Beaupré wrote: >> > I also note #859122 is not marked 'patch'. >> fixed. > > :) > >> >> I've requested access as an individual, for what that's worth. >> > you were given access a week ago, too. \o/ >> yup. I guess I could just merge my own patches now... or do you want to >> review them and do that instead, so we can get at least a second pair of >> eyes on them? > > I just briefly reviewed them (not being a debian-www expert) and they > a.) looked good and b.) only affect our areas, so I do think you should > merge them. i merged both patches, but it doesn't look like the change showed up on the main website yet: https://www.debian.org/security/2018/ ... doesn't list any DLA, and those are both 404s: https://www.debian.org/security/2018/dla-1580 https://www.debian.org/security/2018/dla-1561 Any ideas? A. -- Twenty years from now you will be more disappointed by the things that you didn't do than by the ones you did do. So throw off the bowlines. Sail away from the safe harbor. Catch the trade winds in your sails. Explore. Dream. Discover. - Mark Twain
Re: automating process for publishing DLAs on the website
On 2018-12-19 14:44:02, Holger Levsen wrote: > Hi Antoine, > > On Tue, Dec 11, 2018 at 10:15:15AM -0500, Antoine Beaupré wrote: [...] > I also note #859122 is not marked 'patch'. fixed. [...] >> I've requested access as an individual, for what that's worth. > > you were given access a week ago, too. \o/ yup. I guess I could just merge my own patches now... or do you want to review them and do that instead, so we can get at least a second pair of eyes on them? then if all is good I could push a batch to complete the backlog and get us started on an ongoing workflow... >> I've also got feedback from larjona on IRC, saying she didn't have time >> to work on this yet, but ping'd the team to see if someone else >> will. Otherwise she might be able to review our work in January. > > that's almost like next week ;) right, time flies! >> I wonder if we could consider more automation here to remove the manual >> push/pull process, because it seems it will be a significant source of >> friction in our process in the future... > > sure, more automation = better. > >> Anyways, hopefully we'll figure out a workflow soon enough. :) > > I'm confident we will, eventually. #859122 was filed >18 months ago, so > I don't think it's suddenly urgent, though I fully agree it would be > more than nice to have this fixed before the bug is two years old. yep. i'm not in a rush... a. -- One of the strongest motives that leads men to art and science is escape from everyday life with its painful crudity and hopeless dreariness. Such men make this cosmos and its construction the pivot of their emotional life, in order to find the peace and security which they cannot find in the narrow whirlpool of personal experience. - Albert Einstein
Re: HEADS UP: upcoming change to libgcrypt and other gnupg libraries for Enigmail backport
On 2018-12-14 09:08:42, Emilio Pozuelo Monfort wrote: > On 13/12/2018 21:14, Antoine Beaupré wrote: >> Hi, >> >> This is the latest update in the Thunderbird / Enigmail changes that are >> happening in jessie. I have built a series of test packages, partly from >> stretch (gnupg2, enigmail) and partly from backports (libassuan, >> libgcrypt, libgpg-error, npth) and uploaded them here: >> >> https://people.debian.org/~anarcat/debian/jessie-lts/ >> >> I need people to test those packages, and not just enigmail users. Some >> of those packages have pernicious and deep ramifications. I am >> particularly worried about libgcrypt, which is used for example by >> cryptsetup. > > I see that your tests have gone well so far (except for enigmail itself for > unrelated reasons as you explain). This is great work, and I don't mean to > push > back on it. However given the impact of these library updates, I was wondering > if we have considered to just mark enigmail as EOL in jessie? Obviously if we > can keep supporting stuff we should do that, but as you say these library > updates affect important unrelated rdeps so we need to weigh that. I have repeatedly considered this, and received almost zero feedback on the idea, other than "we should support our users", which I took as a go ahead to actually complete the backport. I have outlined the tradeoffs of this in the past. For me, the biggest concern is that users will blindly install Enigmail from the app store and that actually has security vulnerabilities because the jessie gpg version is too old, as I understand it. > BTW I have briefly looked at the versions you have backported, and I wonder > why > npth and libgpg-error have deb8u3 rather than deb8u1? An oversight. I also need to use dh-autoreconf in enigmail as I have been told it actually exists in jessie - not sure how I couldn't find it. :) > I haven't looked at your changes yet, but I will find some time to look at > them > and give these packages a try. Thanks! The more testing we get, the better off we'll be. :) A. -- No animal has more liberty than the cat; but it buries the mess it makes. The cat is the best anarchist. Until they learn that from the cat I cannot respect them. - For whom the bell tolls, Ernest Hemingway
HEADS UP: upcoming change to libgcrypt and other gnupg libraries for Enigmail backport
Hi, This is the latest update in the Thunderbird / Enigmail changes that are happening in jessie. I have built a series of test packages, partly from stretch (gnupg2, enigmail) and partly from backports (libassuan, libgcrypt, libgpg-error, npth) and uploaded them here: https://people.debian.org/~anarcat/debian/jessie-lts/ I need people to test those packages, and not just enigmail users. Some of those packages have pernicious and deep ramifications. I am particularly worried about libgcrypt, which is used for example by cryptsetup. I am also concerned about the interactions between gpg2 and legacy gpg 1.4. I have made sure that gpg binaries are not clobbered by gpg2, which means it *should* be possible to run both side by side. But this does mean having multiple key storage at once when gpg2 is in used, something we have managed to avoid in the 1.4 -> 2.x migration in stretch so far. I am also specifically concerned about statements such as "[even though co-installability was considered while designing 2.1, in practice 1.4 and 2.1+ don't mix well][gnupg]" that were said elsewhere. [gnupg]: https://lists.gnupg.org/pipermail/gnupg-users/2018-February/059988.html Nevertheless, I have gone through the process of testing the packages against their dependencies in a jessie virtual machine, as much as possible. The following tools were tested, based on [advice from dkg][]: * cryptsetup: no build-time test suite, smoke-tested (luksFormat/Open + mkfs + edit file / close loop), main related change is libgpgerror and libgcrypt bumps * gpgme: build-time test suite passes, no further direct test although covered by later mutt tests, i believe * gmime: untested * libotr: depends on libgcrypt11, so presumed not affected. built, but no build-time test suite * mutt: no test suite, segfaults when hitting "enter" when no key match, but bug already present in jessie before proposed changes. other smoke tests seem okay. * claws: untested * mcabber: untested * enigmail: self-test suite passes at build time, had several problems during account setup (revocation cert failed to create during key init; can encrypt to a client, but not sign or decrypt. so something definitely wrong), related to missing pinentry packages. once pinentry is installed, all functionality seems to be working, including receiving and sending encrypted+signed and encrypted emails. autocrypt not tested. Regarding the latter, it seems like autocrypt caused some problems at least with the [Tails team][15923]. It might be advisable to upgrade to Enigmail 2.0.9 in stretch and jessie before completing this work, as it seems to address those issues specifically. [advice from dkg]: https://lists.debian.org/87ftvrnbyb@fifthhorseman.net [15923]: https://redmine.tails.boum.org/code/issues/15923 I would appreciate code reviews, although the changes to perform the backports are generally trivial: downgrade debhelper from 10 to 9, delete the dh-strip --dbgsym-migration overrides, remove the mingw packages, etc. Those who want to review the changes in code might want to use the git repositories on salsa, because all packages are conveniently available there. I created a debian/jessie-security branch on every repository I had write access to, or on a fork in my own namespace otherwise: https://salsa.debian.org/debian/enigmail https://salsa.debian.org/debian/gnupg2 https://salsa.debian.org/debian/libassuan https://salsa.debian.org/anarcat/libgcrypt https://salsa.debian.org/debian/libgpg-error https://salsa.debian.org/anarcat/npth Unless I get significant pushback on this, I plan on uploading those packages next tuesday. Phew! Maybe we'll get through that one at last. :) A. -- Seul a un caractère scientifique ce qui peut être réfuté. Ce qui n'est pas réfutable relève de la magie ou de la mystique. - Karl Popper
Re: Addressing FreeRDP security issues in Debian jessie (and stretch)
Gah. Forgot to fix the CC here as well, sorry for the noise. On 2018-12-11 10:05:53, Antoine Beaupré wrote: > On 2018-12-10 17:44:51, Mike Gabriel wrote: >> Hi, >> >> I'd like to discuss the possible pathways for getting FreeRDP fixed in >> Debian jessie LTS (and Debian stretch, too). >> >> Last week I talked to Bernhard Miklautz (one of the FreeRDP upsteam >> maintainers and the actual packager of FreeRDPv2 in Debian). >> >> 1. Looking at fixing FreeRDP v1.1 in jessie / stretch >> - >> >> He sketched up the following pathway for getting freerdp (v1.1) fixed >> in Debian jessie (and stretch): >> >>* Backport https://github.com/FreeRDP/FreeRDP/pull/4499 >> -> required for FreeRDP in jessie/stretch to be able to connect >> to current RDP servers >> (not a security issue, but a functionality issue due to >> Microsoft updates rolled out >> during Q1 / 2018). >> -> estimated effort: 1-2h >> >>* CVE-2018-8785: not needed for jessie / stretch (code not present) >> >>* CVE-2018-8786, >> CVE-2018-8789: estimated hours for all three: 1-2h >> >>* CVE-2018-8787: estimated hours: 1-2h >>* CVE-2018-8788: can be become quite an effort, estimated time: 2h++ >> >>* CVE-2018-8784: not needed for jessie / stretch (code not present) >> >> >> While this sounds nice and feasible the underlying tone of investing >> so much work into FreeRDP v1.1 was a different one. >> >> E.g. the fix for CVE-2018-8789 should be quick and simple. But the >> surrounding code is buggy to a great extent, too. >> >> There have been so many stabilizing code fixes over the past 1-2 years. >> >> >> 2. Backporting FreeRDP v2 from buster to jessie and stretch >> >> >> Another approach, with a more stable and usable result is backporting >> FreeRDP v2 to jessie and stretch right away. >> >> Most people (I hope) are using freerdp2-x11 from stretch-backports >> (plus remmina from stretch-bpo) on Debian stable these days (freerdp >> 1.1 in stretch is broken with Windows RDP servers that are up-to-date >> with their patch levels). >> >> libfreerdp-client1.1 >>Reverse Depends: freerdp-x11 (>= >> 1.1.0~git20140921.1.440916e+dfsg1-4+deb8u1) >>Reverse Depends: libfreerdp-dbg (= >> 1.1.0~git20140921.1.440916e+dfsg1-4+deb8u1) >>Reverse Depends: libfreerdp-dev (= >> 1.1.0~git20140921.1.440916e+dfsg1-4+deb8u1) >>Reverse Depends: libguac-client-rdp0 (>= 0.8.3-1+b2) >>Reverse Depends: libxfreerdp-client1.1 (>= >> 1.1.0~git20140921.1.440916e+dfsg1-4+deb8u1) >>Reverse Depends: remmina-plugin-rdp (>= 1.1.1-2) >>Reverse Depends: vlc (>= 2.2.7-1~deb8u1) >> freerdp-x11 >>Reverse Depends: freerdp-x11-dbg (= >> 1.1.0~git20140921.1.440916e+dfsg1-4+deb8u1) >>Reverse Depends: ltsp-client (5.5.4-4) >> >> So the plan could be this: >> >>- rebuild freerdp (v1.1) as a shared libs package only, drop >> freerdp-x11 (which >> contains the command line tool) >> >>- backport freerdp2 from Debian unstable to jessie/stretch >>- backport remmina from Debian unstable to jessie/stretch >>- rebuild vlc in jessie (and possibly stretch, too) without RDP support >>- ltsp-client: adapt command line syntax to new FreeRDP2 cli style > > That sounds like a large change, especially about dropping RDP support > from VLC... Do we have any idea about how VLC uses RDP and how many of > our users expect that to work in the first place? How about changes in > remmima? > >>- libguac-client-rdp0: leave as is... Guacamole upstream still believes in >> FreeRDP v1.1 shared lib API... > > "Believes"? I don't understand this point... > >> Summary >> --- >> >> Before going any deeper into this, I'd love to get some feedback from >> the LTS and the security team about the proposed strategies. Are there >> other possible pathways to go? If so, please share yours. >> >> The FreeRDP v1.1 backporting work (8-10 hours) would have to be >> outsourced to ThinCast in Austria (where most FreeRDP upstream devs >> work these days). > > I don't know of any other pathways, but from what I understand we have > some extra hours to spare, so we could allow ourselves such an expense > to keep jessie ... "stable". :) > > A. > -- > Dans vos mensonges de pierre > Vous gaspillez le soleil > - Gilles Vigneault -- Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. - Brian W. Kernighan
Re: automating process for publishing DLAs on the website
On 2018-11-20 15:30:21, Holger Levsen wrote: > On Mon, Nov 19, 2018 at 07:07:26PM -0500, Antoine Beaupré wrote: >> The process broke down a while back, and reasons don't matter. We need >> to figure out how to fix this. >> >> So I opened #859122 to import the missing DLAs and I've made good >> progress. >> >> But I've opened this bug report (#859123) to fix the process. So far, >> the idea we had was to make LTS contributors submit a patch to the >> website as part of the DLA publication process. You'd run the little >> "parse-dla.pl" script which would create two files in the webwml git >> repository, separate from the security tracker! that's where the >> debian.org website lives.. Then you'd commit those and send a merge >> request to the project (or just push if you have the rights). The >> webmaster folks seemed to be open to grant us access to the repo to >> remove friction as well.. >> >> How does that sound? > > sounds very good to me. thanks for your work on this so far! Right, agreed. :) I guess the script could both parse previous emails and future ones quite easily. The problem we have right now is we have no feedback from the www team on the patches proposed in #859122 so I don't know if the formatting is alright. Nor is it promising for the promptness with which the team can respond to our constant flurry of such MRs in the future... >> Another thing I thought we could do would be to hook that script into a >> mailbox that would receive mail from the debian-lts-announce list and >> automatically publish the results into git. But so far my efforts at >> automating things on Debian infrastructure have mostly failed, so I'm >> not sure it's the way to go. Besides, the parse-dsa.pl script isn't >> exactly solid, and don't like the idea of parsing arbitrary input like >> this without a human oversight. But it would certainly reduce friction >> to a minimum, which I like. > > I better like your above proposal than generating data from parsing mails > which > we have sent previously. > > So I've just requested webwml access from the debian-www folks. ... where did you do that? Considering that the patches I proposed now 3 weeks ago haven't been merged, it seems it would be imperative for all LTS people to have access to the www repository in our workflow. Or at least a significant numebr of people. Otherwise we'll just be clogging their review queue forever. I've requested access as an individual, for what that's worth. I've also got feedback from larjona on IRC, saying she didn't have time to work on this yet, but ping'd the team to see if someone else will. Otherwise she might be able to review our work in January. I wonder if we could consider more automation here to remove the manual push/pull process, because it seems it will be a significant source of friction in our process in the future... Anyways, hopefully we'll figure out a workflow soon enough. :) A. A. -- Gods don't like people not doing much work. People who aren't busy all the time might start to think. - Terry Pratchett, Small Gods
Re: Addressing FreeRDP security issues in Debian jessie (and stretch)
On 2018-12-10 17:44:51, Mike Gabriel wrote: > Hi, > > I'd like to discuss the possible pathways for getting FreeRDP fixed in > Debian jessie LTS (and Debian stretch, too). > > Last week I talked to Bernhard Miklautz (one of the FreeRDP upsteam > maintainers and the actual packager of FreeRDPv2 in Debian). > > 1. Looking at fixing FreeRDP v1.1 in jessie / stretch > - > > He sketched up the following pathway for getting freerdp (v1.1) fixed > in Debian jessie (and stretch): > >* Backport https://github.com/FreeRDP/FreeRDP/pull/4499 > -> required for FreeRDP in jessie/stretch to be able to connect > to current RDP servers > (not a security issue, but a functionality issue due to > Microsoft updates rolled out > during Q1 / 2018). > -> estimated effort: 1-2h > >* CVE-2018-8785: not needed for jessie / stretch (code not present) > >* CVE-2018-8786, > CVE-2018-8789: estimated hours for all three: 1-2h > >* CVE-2018-8787: estimated hours: 1-2h >* CVE-2018-8788: can be become quite an effort, estimated time: 2h++ > >* CVE-2018-8784: not needed for jessie / stretch (code not present) > > > While this sounds nice and feasible the underlying tone of investing > so much work into FreeRDP v1.1 was a different one. > > E.g. the fix for CVE-2018-8789 should be quick and simple. But the > surrounding code is buggy to a great extent, too. > > There have been so many stabilizing code fixes over the past 1-2 years. > > > 2. Backporting FreeRDP v2 from buster to jessie and stretch > > > Another approach, with a more stable and usable result is backporting > FreeRDP v2 to jessie and stretch right away. > > Most people (I hope) are using freerdp2-x11 from stretch-backports > (plus remmina from stretch-bpo) on Debian stable these days (freerdp > 1.1 in stretch is broken with Windows RDP servers that are up-to-date > with their patch levels). > > libfreerdp-client1.1 >Reverse Depends: freerdp-x11 (>= > 1.1.0~git20140921.1.440916e+dfsg1-4+deb8u1) >Reverse Depends: libfreerdp-dbg (= > 1.1.0~git20140921.1.440916e+dfsg1-4+deb8u1) >Reverse Depends: libfreerdp-dev (= > 1.1.0~git20140921.1.440916e+dfsg1-4+deb8u1) >Reverse Depends: libguac-client-rdp0 (>= 0.8.3-1+b2) >Reverse Depends: libxfreerdp-client1.1 (>= > 1.1.0~git20140921.1.440916e+dfsg1-4+deb8u1) >Reverse Depends: remmina-plugin-rdp (>= 1.1.1-2) >Reverse Depends: vlc (>= 2.2.7-1~deb8u1) > freerdp-x11 >Reverse Depends: freerdp-x11-dbg (= > 1.1.0~git20140921.1.440916e+dfsg1-4+deb8u1) >Reverse Depends: ltsp-client (5.5.4-4) > > So the plan could be this: > >- rebuild freerdp (v1.1) as a shared libs package only, drop > freerdp-x11 (which > contains the command line tool) > >- backport freerdp2 from Debian unstable to jessie/stretch >- backport remmina from Debian unstable to jessie/stretch >- rebuild vlc in jessie (and possibly stretch, too) without RDP support >- ltsp-client: adapt command line syntax to new FreeRDP2 cli style That sounds like a large change, especially about dropping RDP support from VLC... Do we have any idea about how VLC uses RDP and how many of our users expect that to work in the first place? How about changes in remmima? >- libguac-client-rdp0: leave as is... Guacamole upstream still believes in > FreeRDP v1.1 shared lib API... "Believes"? I don't understand this point... > Summary > --- > > Before going any deeper into this, I'd love to get some feedback from > the LTS and the security team about the proposed strategies. Are there > other possible pathways to go? If so, please share yours. > > The FreeRDP v1.1 backporting work (8-10 hours) would have to be > outsourced to ThinCast in Austria (where most FreeRDP upstream devs > work these days). I don't know of any other pathways, but from what I understand we have some extra hours to spare, so we could allow ourselves such an expense to keep jessie ... "stable". :) A. -- Dans vos mensonges de pierre Vous gaspillez le soleil - Gilles Vigneault
Re: Xen 4.4 updates vs. Xen Stretch backport
On 2018-12-03 20:40:08, Ben Hutchings wrote: [...] > I don't see this as an acceptable option for LTS. We could maybe add a > xen-4.8 package if it was popular in jessie-backports, but that doesn't > excuse us from having to support 4.4. As I was repeatedly told during my work on Enigmail / GnuPG, I will myself remind us all that jessie-backports is unfortunately not an option anymore. :) A. -- Qui vit sans folie n'est pas si sage qu'il croit. - François de La Rochefoucauld
Re: Xen 4.4 updates vs. Xen Stretch backport
On 2018-11-28 22:44:52, Moritz Muehlenhoff wrote: > On Wed, Nov 28, 2018 at 12:59:11PM +0100, Peter Dreuw wrote: >> Hi out there, >> Another option would be backporting the Xen >> 4.8.4+xsa273+shim4.10.1+xsa273-1+deb9u10 (and following) package from >> Stretch to Jessie. > > What would be the point? If you migrate to a complete new Xen release, > then you can just as well migrate to stretch (which will also have > proven, compatible matching versions of libvirt/Linux/qemu/ etc. > > If some of the Spectre mitigations can't be backported, make a detailed > writeup of what people are missing in 4.4 and let them handle it > based on that data (update to stretch or stick with 4.4/jessie); there's > still plenty of legitimate use cases which can be run in a secure > manner with 4.4 (internal VMs with trusted users etc). I agree. It's not like Spectre is trivial to exploit either, so the tradeoff might be acceptable for some users. Xen upgrades are usually fairly smooth, but considering the dom0 is most likely *only* running Xen, upgrading to stretch is probably equivalent than upgrading to a Xen backported from stretch. So while I usually am a proponent of aggressive backports, I think that, in this case, we would actually be doing a disservice to our users by forcibly backporting a version from stretch. :) Peter, are there non-speculative vulnerabilities remaining we could look at? Otherwise I would just publish a DLA saying we simply stop supporting that aspect of Xen... A. -- The future is already here – it's just not very evenly distributed. - William Gibson
Re: unclaiming packages claimed for 3 weeks or more (Re: november report)
On 2018-11-26 21:20:14, Holger Levsen wrote: > On Mon, Nov 26, 2018 at 04:04:48PM -0500, Antoine Beaupré wrote: >> Did you try "--exclude linux linux 4.9"? That should work. > > doh, it does. Thanks! (Though I think thats somewhat unusual... but meh.) that's the way all python-argparsed-based commandline parsers work, for what that's worth. a. -- The good news about computers is that they do what you tell them to do. The bad news is that they do what you tell them to do. - Ted Nelson
Re: unclaiming packages claimed for 3 weeks or more (Re: november report)
On 2018-11-26 20:48:07, Holger Levsen wrote: > On Fri, Nov 23, 2018 at 11:06:43AM -0500, Antoine Beaupré wrote: >> $ ./bin/review-update-needed --exclude linux linux-4.9 --lts --unclaim 3w >> [...] >> Editing file to unclaim: salt >> >> I've pushed that, I hope it works for you. > > this indeed works, however I didnt find a way to ignore both linux and > linux-4.9, neither "--exclude linux --exclude linux-4.9" nor "exclude > linux,linux-4.9" nor a bunch of other combinations worked. Did you try "--exclude linux linux 4.9"? That should work. > Also, I found another small bug: when I used the script without > --exclude option (and with --unclaim 3w --lts) it would currently > unclaim salt, linux and linux-4.9, however the generated diff/edit is > (with context lines removed) > > -linux (Ben Hutchings) > +linux > -linux-4.9 (Ben Hutchings) > +linux > -salt (Mike Gabriel) > +salt > > while it should be: > > -linux (Ben Hutchings) > +linux > -linux-4.9 (Ben Hutchings) > +linux-4.9 > -salt (Mike Gabriel) > +salt > > (the diff is +linux-4.9 instead of twice +linux) oops. fixed. a. -- Modern man has a kind of poverty of the spirit which stands in great contrast to his remarkable scientific and technological achievements. We've learned to walk in outer space and yet we haven't learned to walk to earth as brothers and sisters. - Martin Luther King, Jr.
Re: unclaiming packages claimed for 3 weeks or more (Re: november report)
On 2018-11-22 21:00:15, Holger Levsen wrote: > On Thu, Nov 22, 2018 at 11:54:16AM -0500, Antoine Beaupré wrote: >> Right. That's the one I had in mind as well. :) > > :) > >> So how *do* we make that "whitelist"? Commandline param? And what will >> it list? Packages? People? Package/people combination? > > commandline param with a list of (src) packages to ignore. Okay, I added a --exclude param. Example without: $ ./bin/review-update-needed --lts --unclaim 3w [...] Editing file to unclaim: linux, linux-4.9, salt With: $ ./bin/review-update-needed --exclude linux linux-4.9 --lts --unclaim 3w [...] Editing file to unclaim: salt I've pushed that, I hope it works for you. A. -- The secret of life is to have no fear; it's the only way to function. - Stokely Carmichael
Re: the way to enigmail: gnupg 2.1 backport considerations
On 2018-11-22 17:32:09, Holger Levsen wrote: > On Thu, Nov 22, 2018 at 10:54:41AM -0500, Antoine Beaupré wrote: >> On 2018-11-20 12:55:16, Daniel Kahn Gillmor wrote: >> > All that said, i don't think that upgrading jessie to the versions of >> > these libraries that are in debian stretch will break jessie. I do wish >> > we had more substantive autopkgtest-style coverage in jessie, so that we >> > could feel more confident about this, but i don't think we currently do. >> So this goes back to the question of whether we should test this >> further, either ourselves or through this list's participants. > > more tests are always good. sorry, i'm a bit lost here: are (source and > binary) > packages available for testing? Yes, the head email on 87r2fqnja0@curie.anarc.at links to the test packages: https://people.debian.org/~anarcat/debian/jessie-lts/gnupg2_2.1.18-8~deb8u3_amd64.changes The dependencies are in backports. A. -- La seule excuse de Dieu, c'est qu'il n'existe pas. - Stendhal
Re: unclaiming packages claimed for 3 weeks or more (Re: november report)
On 2018-11-20 16:17:57, Holger Levsen wrote: > Hi, > > So I ran it asking it to unclaim packages which didnt see activity in > dla-needed.txt for more than 3 weeks. These are the results from running > ./bin/review-update-needed --lts --unclaim 1814400 [...] > -linux (Ben Hutchings) > +linux > and > -linux-4.9 (Ben Hutchings) > +linux > (here I think I would like to be able to whitelist this as Ben currently > always takes these packages.) Right. That's the one I had in mind as well. :) So how *do* we make that "whitelist"? Commandline param? And what will it list? Packages? People? Package/people combination? Before you answer, consider that all entries are manually maintained and I sometimes write my name "Antoine Beaupre", "Antoine Beaupré" or "anarcat" depending on what I remember I used last, and that last time we dealt we accents, the script crashed. :p > -nsis (Thorsten Alteholz) > +nsis > last NOTE: 20181110: waiting for email answer > so here the script is buggy, this should not have been unclaimed! > > -openjpeg2 (Hugo Lefeuvre) > +openjpeg2 > last NOTE: *doesnt have a date to it* > still there is last-update in the output and it says "Last-Update: 2018-11-19 > 19:02" > so I believe the script is buggy. > > -qemu (Santiago) > +qemu > NOTE: 20181026: no fix yet for recent dsa issues, but start working on > NOTE: pending no-dsa issues > Technically correctly unclaimed (as last edit was 26 days ago), however > given the notes I think this should stay as it is. > > -symfony (Thorsten Alteholz) > +symfony > NOTE: 20181110: patches ready, struggling with test suite, waiting for email > another bug in the script, this should not have been unclaimed. > > Conclusion: the script has potential but is still too buggy ;) Yep. Silly me, I only looked at claimed-date and not "last-update". I pushed this fix and the output changes to implement the things we discussed. Hopefully it will help us move forward. :) I bypassed the MR process as indicated in private: I am going under the assertion that the secteam is not using this script anyways and we shouldn't bother them with our administrativia any further. The only thing that remains unclear to me is the opt-out mechanisms. I believe everyone should be "opted in" by default and we can add exceptions. The only question is how. I can think of two ways: 1. manually: the operator (or cronjob) passes a list of "things" to the script that then get ignored 2. automatically: the script reads "things" from a file next to or close to the dla-needed file We also need to figure out what the "things" are (package, owner, or package-owner tuple), as I mentioned above. Thanks! A. -- Modern man has a kind of poverty of the spirit which stands in great contrast to his remarkable scientific and technological achievements. We've learned to walk in outer space and yet we haven't learned to walk to earth as brothers and sisters. - Martin Luther King, Jr.
Re: feedback on review-update-needed --lts --unclaim (Re: november report)
On 2018-11-20 16:06:53, Holger Levsen wrote:
> hi,
>
> this reply is mostly about using the tool itself, see below. I will now write
> another mail about the results from using it...
>
[...]
> So, third, what did "./bin/review-update-needed --unclaim --lts" do? Too
> much, so I ran (in a sid schroot where I have python3-humanfriendly
> installed) this: "schroot -- ./bin/review-update-needed --lts --unclaim 3w"
> and got:
>
> [output and]
> Traceback (most recent call last):
> File "./bin/review-update-needed", line 129, in
> args.quiet or print("Claimed-By: {}".format(entry['claimed-by']))
> UnicodeEncodeError: 'ascii' codec can't encode character '\xe1' in position
> 24: ordinal not in range(128)
>
> (This only happens if I run ./bin/review-update-needed in schroot.)
Strange. I can't reproduce this in buster! It's especially strange that
this occurs in that segment, which I haven't really touched... I only
addded that "args.quiet or" there, but the "Claimed-by" has been there
for a while...
> However no changes were made.
Yeah, that's a total, typical, python unicode crash. :p Could you give
me more information on your locale? It looks like you don't have a UTF-8
locale, which will, naturally, cause problems when trying to display
non-ASCII characters in Python. There are workarounds for this, but I'm
not sure we should go through that trouble considering we control that
environment pretty well and it's fair to assume utf8...
> Fourth, the order of entries in the output and in data/dla-needed.txt is
> different, which is confusing and makes it harder to find entries, could
> that be fixed?
the list is sorted according to the `--sort-by`. We could add a
"unsorted" argument to that (or make that the default). What do you
prefer?
> Fifth, if a package is unclaimed, it would be good to include this in
> the package related output (and not just in the summary in the end), so
> instead of for example:
>
> Package: icecast2
> Claimed-By: Abhijith PA
> Claimed-Date: 2018-11-04 11:25 (16 days ago)
> Last-Update: 2018-11-06 09:46 (14 days ago)
>
> it would be nicer if the output were
>
> Package: icecast2
> Claimed-By: Abhijith PA
> Claimed-Date: 2018-11-04 11:25 (16 days ago)
> Last-Update: 2018-11-06 09:46 (14 days ago)
> Unclaimed because last update was more than $timespan ago.
That's totally doable though. How does that look for you?
diff --git i/bin/review-update-needed w/bin/review-update-needed
index 976c0e9c82..fe4103b0d1 100755
--- i/bin/review-update-needed
+++ w/bin/review-update-needed
@@ -133,6 +133,7 @@ for entry in all_entries:
date_to_format = datetime.utcfromtimestamp(entry['claimed-date'])
if datetime.utcnow() - date_to_format > unclaim_delta:
unclaim_pkgs.append(entry['pkg'])
+args.quiet or print("Unclaimed: idle for more than {}:
{}".format(unclaim_delta, datetime.utcnow() - date_to_format))
else:
args.quiet or print("Unclaimed-Since:
{}".format(format_date(entry['claimed-date'])))
if entry['last-update'] > entry['claimed-date']:
@@ -149,7 +150,7 @@ for entry in all_entries:
print("")
if args.unclaim:
-args.quiet or print("Packages to unclaim: {}".format(",
".join(unclaim_pkgs)))
+args.quiet or print("Editing file to unclaim: {}".format(",
".join(unclaim_pkgs)))
in_preamble = True
with open(dsa_dla_needed) as orig, open(dsa_dla_needed + '.new', 'w') as
new:
for line in orig:
> Six, I ran "./bin/review-update-needed --lts --unclaim 1814400" on
> stretch and got useful output which I will summarize in another mail,
> so that we have one thread about improving the tool and another about
> unclaiming specific packages.
Awesome.
I'm surprised you're not getting the unicode error there though. Maybe
it's because UTF-8 locales are not setup in the schroot?
A.
--
Isn't man but a blossom taken by the wind, and only the mountains and
the sea and the stars and this Land of the Gods real and everlasting?
- James Clavell, Shōgun
Re: the way to enigmail: gnupg 2.1 backport considerations
On 2018-11-20 12:55:16, Daniel Kahn Gillmor wrote: > All that said, i don't think that upgrading jessie to the versions of > these libraries that are in debian stretch will break jessie. I do wish > we had more substantive autopkgtest-style coverage in jessie, so that we > could feel more confident about this, but i don't think we currently do. So this goes back to the question of whether we should test this further, either ourselves or through this list's participants. I was hoping publishing the test package would trigger some feedback; it didn't. While I can do some tests of my own, the surface area of this is so vast that it feels somewhat pointless to run discrete tests. What's the best way to resolve this? A. -- Blind respect for authority is the greatest enemy of truth. - Albert Einstein
Re: the way to enigmail: gnupg 2.1 backport considerations
On 2018-11-20 15:19:45, Ben Hutchings wrote:
> On Mon, 2018-11-19 at 15:48 -0500, 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.
> [...]
>
> Those updated library packages are installed and used by people that
> specifically choose to use GnuPG 2.1 in jessie. I don't think we can
> assume they are well-tested in conjunction with GnuPG 1.4.
My understanding is that GnuPG 1.4 does not use those libraries at all,
and from what I can tell, gpg 1.4 does not link against them either.
A.
--
On reconnait la grandeur et la valeur d'une nation à la façon dont
celle-ci traite ses animaux.
- Mahatma Gandhi
automating process for publishing DLAs on the website
Hi! Many of you probably already know this website and its precious RSS feed: https://www.debian.org/security/ Few of you might already know that DLAs are *supposed* to show up in there as well, and did for a while. For example, here's a few DLAs in 2014: https://www.debian.org/security/2014/ The process broke down a while back, and reasons don't matter. We need to figure out how to fix this. So I opened #859122 to import the missing DLAs and I've made good progress. But I've opened this bug report (#859123) to fix the process. So far, the idea we had was to make LTS contributors submit a patch to the website as part of the DLA publication process. You'd run the little "parse-dla.pl" script which would create two files in the webwml git repository, separate from the security tracker! that's where the debian.org website lives.. Then you'd commit those and send a merge request to the project (or just push if you have the rights). The webmaster folks seemed to be open to grant us access to the repo to remove friction as well.. How does that sound? Another thing I thought we could do would be to hook that script into a mailbox that would receive mail from the debian-lts-announce list and automatically publish the results into git. But so far my efforts at automating things on Debian infrastructure have mostly failed, so I'm not sure it's the way to go. Besides, the parse-dsa.pl script isn't exactly solid, and don't like the idea of parsing arbitrary input like this without a human oversight. But it would certainly reduce friction to a minimum, which I like. Any other ideas? Thanks! A. -- Only in the darkness can you see the stars. - Martin Luther King, Jr.
november report
An early report, this month, as I've ran out of work hours earlier than expected... GnuPG & Enigmail To get Enigmail working properly with the Thunderbird upload from last week, we need GnuPG 2.1 in jessie. I [backported GnuPG 2.1][] to Debian jessie directly, using work already done to backport the required libraries from jessie-backports. It was [proposed][2] to ship the libraries as private libraries or statically link GnuPG itself. I believe this is the wrong approach and besides I'm unsure as to how this would work in practice, so I recommend going forward with the libraries backport. I provided a [summary][3] of the conversation to try and bring a conclusion. [1]: https://lists.debian.org/87r2fqnja0@curie.anarc.at [2]: https://lists.debian.org/0c03ba38-26f5-8e45-d792-5b1871a4d...@gmail.com [3]: https://lists.debian.org/87sgzw7q7k@curie.anarc.at Spamassassin Once Spamassassin 3.4.2 was [accepted][4] in the latest stable point release, I went back to work on the jessie upgrade I [proposed last month][5] and uploaded the resulting package as [DLA-1578-1][]. [4]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912198#36 [5]: https://lists.debian.org/87h8h39she@curie.anarc.at [DLA-1578-1]: https://lists.debian.org/20181113190619.ga15...@curie.anarc.at Security tracker I worked on a few sticky parts of the security tracker. Automatic unclaimer --- After an internal discussion about work procedures, a friend pointed me at the [don't lick the cookie][6] article which I found really interesting. The basic idea is that our procedure for work distribution is based on "claims" which mean some packages remain claimed for extended periods of time. [6]: https://www.benday.com/2016/10/21/scrum-dont-lick-the-cookie/ For some packages it makes sense: the kernel updates, for example, have been consistently and dilligently performed by Ben Hutchings for as long as I remember, and I myself would be very hesitant in claiming that package myself. In that case it makes sense that the package remains claimed for a long time. But for some other packages, it's just an oversight: you claim the package, work on it for a while, then get distracted by more urgent work. It happens all the time, to everyone. The problem is then that the work is stalled and, in the meantime, other people looking for work are faced with a long list of claimed packages. In theory, we are allowed to "unclaim" a package that's been idle for too long, but as the article describes, there's a huge "emotional cost" associated with making such a move. So I looked at automating this process and [unclaim packages automatically][7]. This was originally rejected by the security team which might have confused the script implementation with a separate [proposal][8] to add a cronjob on the security tracker servers to automate the process there. [7]: https://salsa.debian.org/security-tracker-team/security-tracker/merge_requests/23 [8]: https://salsa.debian.org/security-tracker-team/security-tracker-service/merge_requests/2 After some tweaking and bugfixing, I believe the script is ready for use and our new LTS coordinator will give it a try, in what I would describe as a "manually triggered automatic process" while with figure out if the process will work for us. Splitting huge files in the repository -- I once again looked at splitting the large (17MB and counting) `data/CVE/list` file in the security tracker. While my [first attempt][9] was just trying to improve performance in my own checkouts, the heaviness of the repository has now been noticed by the Salsa administrators (bug #908678) as it triggers several performance issues in GitLab. [9]: https://salsa.debian.org/security-tracker-team/security-tracker/issues/2 And while my first attempt clearly not a good tradeoff and made performance worse (by splitting each CVE in its own file), the new proposal (split by year) actually brings significant performance improvements. Clones takes 11 times less space (145MB vs 1.6GB) and resolve ten times faster (2 vs 21 minutes, local only). Running annotate on one year takes 26 seconds while running this takes around 10 minutes over the whole file. This arguably, is less impressive: there are, after all, twenty years of history in that repository, so to be fair, we'd need to run annotate against all of those. But obviously, earlier years are smaller than the latest, so the total is also faster (2 minutes). And besides, we don't really need to run annotate against the *entire* file: when I do this, I usually want to know who to contact about a comment in the file, which is usually a recent change. The conversion itself was an interesting exercise in optimisation. The original tool was a simple bash script, which split the file in 15 seconds, which is fine if we are ready to lose history in the repository, But that is probably un
Re: the way to enigmail: gnupg 2.1 backport considerations
On 2018-11-19 22:32:17, Alexander Wirt wrote: > 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. I'm sorry I implied we might use backports for this. I didn't mean to: I mean we should take what has been backported in jessie-backports and upload that to jessie-security. A. -- If builders built houses the way programmers built programs, The first woodpecker to come along would destroy civilization. - Gerald Weinberg
Re: the way to enigmail: gnupg 2.1 backport considerations
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.
A.
--
Premature optimization is the root of all evil
- Donald Knuth
Re: the way to enigmail: gnupg 2.1 backport considerations
Hi, As I'm running out of time to work on this problem for the month, I figured I would at least try to wrap up the conversation we had on the topic here so we can find a solution to move forward on. The current situation is that I have a backport of GnuPG 2.1 available for testing here: https://people.debian.org/~anarcat/debian/jessie-lts/ It should work with the libraries from jessie-backports, and I haven't heard any negative (or positive) feedback on the build, so I'm going under the assertion that it doesn't cause too much trouble. The blocker is it depends on those four jessie-backports libraries: * libassuan (2.1 -> 2.4) * libgcrypt20 (1.6 -> 1.7) * libgpg-error (1.17 -> 1.26) * npth (1.0 -> 1.3) All four libraries are GnuPG-specific libraries that GnuPG 1.4 does *not* currently use. They *are*, however, used by GPGME so that means they are (transitively) linked into any package linking against libgpgme (and there are quite a few of those). I do hope that GPGME would insulate consumers from such changes however. Updating gpg through backports is not possible: -backports is closed and will be archived soon. I have therefore proposed to simply ship the four libraries backports in jessie directly. The concern is that those library updates are not "bugfix-only" releases and might not be suitable fo sur updates. An alternative approach would be to statically link gnupg2 against those libraries or ship them as private copies, possibly as a separate binary package, that would remain as cruft that a stretch upgrade would 'apt autoremove'. So that's the state of affairs. How do we move forward? I've unassigned myself the Enigmail package to allow others to take a shot at this in the next two weeks. Have fun! A. -- You can't conquer a free man; the most you can do is kill him. - Robert A. Heinlein
systemd test packages, without tmpfiles fixes
Hi, Tl;DR: partial fixes for systemd issues pending upload, test packages at usual location. I've been working for the last two days on backporting the four pending CVEs for systemd. Those are: CVE-2018-1049 In systemd prior to 234 a race condition exists between .mount and ... CVE-2018-15688 buffer overflow vulnerability in the dhcp6 client of systemd allows ... CVE-2018-15686 A vulnerability in unit_deserialize of systemd allows an attacker to ... CVE-2018-6954 systemd-tmpfiles in systemd through 237 mishandles symlinks present in ... The first three were fairly easy to backport. CVE-2018-15686 required a bit more work, but that was nothing compared to CVE-2018-6954. The tempfiles "fixes" are ... challenging, to put it mildly. The implementation between jessie and sid varies quite a bit (no ACL/subvolumes support, major API differences) so backporting the changes is definitely non-trivial. I've been battling quilt and upstream patchsets for hours now, and I can't see the end. Every time I go through the "backport, compile, fix" cycle, I uncover a new thread of code I need to backport upstream for the code to make sense. So I'm giving up on this fix for now. It' just too huge. In comparison, the fix for the previous tmpfiles security issue (CVE-2017-18078, currently unfixed) was a breeze - I backported it in a few minutes, thinking it would help resolve the fuzz for the next patches. Far from it. As a safety precaution, I had uploaded a test package to the usual location before working on the tmpfiles work, here: https://people.debian.org/~anarcat/debian/jessie-lts/ So I intend to upload *those* packages some time next week unless otherwise noted. An alternative to backporting the numerous tmpfiles patches from upstream would be to backport *all* of tmpfiles.c itself from buster or sid. Unfortunately, like many parts of systemd, it's not exactly standalone and would imply significant behavior changes, although we could remove the extra functionality introduced in the later releases and focus on the pieces already present in jessie. I believe that it would be the simplest and safest way to approach this, because backporting the patches themselves is a complete nightmare: upstream is constantly going back and forth in critical API changes (like passing a fd or path) which makes it near impossible to settle on a target across releases. I must also admit that it doesn't help that I'm doing this only with quilt, as opposed to cherry-picking upstream patches through git. Unfortunately, even that is a significant challenge: the complete tmpfiles fix is in #8822, which is a whopping 26 commits, rewriting most of tmpfiles.c functions and doing a significant refactoring of everything. Now if you'll excuse me I'll go out enjoy this beautiful snow and nurse that damaged brain of mine for sunnier days. ;) A. -- They say that time changes things, but you actually have to change them yourself. - Andy Warhol
Re: the way to enigmail: gnupg 2.1 backport considerations
On 2018-11-13 18:41:47, Emilio Pozuelo Monfort wrote: > I can think of two options: > > 1) Ship them in a private dir (e.g. /usr/lib/gnupg2/), and link them to those > libs. Then ld should add an RPATH, otherwise an LD_LIBRARY_PATH hack could be > used. > > 2) Statically link the libraries into gpg2 But then that means double the work to maintain those libraries in the future, with duplicate code copies and all. What are we actually worried about regarding those libs? They are only used by gnupg, really - gnutls uses nettle now - so the one thing they would break would be gnupg 1.4... Maybe we could just test that and see where it brings us instead of mangling those libraries? :) A. -- Brief is this existence, as a fleeting visit in a strange house. The path to be pursued is poorly lit by a flickering consciousness. - Albert Einstein
Re: the way to enigmail: gnupg 2.1 backport considerations
On 2018-11-13 13:24:39, Ben Hutchings wrote: > On Mon, 2018-11-12 at 15:16 -0500, 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. >> >> That would mean, however, a more or less forced update on the following >> libraries in jessie: >> >> * libassuan (part of GPG, 2.1 -> 2.4) >> * libgcrypt20 (part of GnuTLS, 1.6 -> 1.7) >> * libgpg-error (GPG, 1.17 -> 1.26) >> * npth (GPG, 1.0 -> 1.3) >> >> How should we handle this? I haven't looked at each backport in detail >> to see if ABI changes are significant, but the version numbers seem to >> indicate they are not (for what that's worth of course). > [...] > > Unless these are bug-fix-only updates, I don't think they are suitable > for jessie-security. I doubt they are: https://tracker.debian.org/media/packages/liba/libassuan/changelog-2.4.3-2~bpo8%2B1 https://tracker.debian.org/media/packages/libg/libgcrypt20/changelog-1.7.6-1~bpo8%2B1 https://tracker.debian.org/media/packages/libg/libgpg-error/changelog-1.26-2~bpo8%2B1 https://tracker.debian.org/media/packages/n/npth/changelog-1.3-1~bpo8%2B1 Lots of "new upstream release" in there which can basically mean anything. Here are the respective changelogs: https://sources.debian.org/src/libassuan/2.4.3-2%7Ebpo8+1/ChangeLog/ https://sources.debian.org/src/libgcrypt20/1.7.6-1%7Ebpo8+1/ChangeLog/ https://sources.debian.org/src/libgpg-error/1.26-2%7Ebpo8+1/ChangeLog/ https://sources.debian.org/src/npth/1.3-1%7Ebpo8+1/ChangeLog/ None of those are patch releases. In fact, in some cases, there *are* no patch releases (e.g. libpth) and I doubt minor releases are really minor anyways... So yes, those are significant upgrades. I take solace in the fact that those packages are on jessie-backports already and that if they would have broken stuff, people would have noticed already... ... right? :) > Would it be possible to bundle the libraries with gpg 2.1, and install > them somewhere that doesn't conflict with the existing versions? That is a possibility. libassuan, for example, is basically this in jessie right now: /usr/lib/x86_64-linux-gnu/libassuan.so.0.4.2 jessie-backports ships: /usr/lib/x86_64-linux-gnu/libassuan.so.0.7.3 both share the same major SONAME, unfortunately. So they is a clash on the .so.0 symlink. I am not sure how the linker could handle duplicates of those entries. And we'd have trouble in /usr/share/doc/libassuan0, for example. libgcrypt is similar: /lib/x86_64-linux-gnu/libgcrypt.so.20.0.3 /lib/x86_64-linux-gnu/libgcrypt.so.20.1.6 libgpg-error: /lib/x86_64-linux-gnu/libgpg-error.so.0.13.0 /lib/x86_64-linux-gnu/libgpg-error.so.0.21.0 libnpth0: /usr/lib/x86_64-linux-gnu/libnpth.so.0.0.3 /usr/lib/x86_64-linux-gnu/libnpth.so.0.0.6 I am not sure how we could ship both versions of those libraries in jessie - that's beyond my linker skill level, i'm afraid. ;) A. -- A genius is someone who discovers that the stone that falls and the moon that doesn't fall represent one and the same phenomenon. - Ernesto Sabato
the way to enigmail: gnupg 2.1 backport considerations
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. That would mean, however, a more or less forced update on the following libraries in jessie: * libassuan (part of GPG, 2.1 -> 2.4) * libgcrypt20 (part of GnuTLS, 1.6 -> 1.7) * libgpg-error (GPG, 1.17 -> 1.26) * npth (GPG, 1.0 -> 1.3) How should we handle this? I haven't looked at each backport in detail to see if ABI changes are significant, but the version numbers seem to indicate they are not (for what that's worth of course). That said, with minor changes (to keep "gpg" pointing at the legacy 1.4 version, most notably), I've got a GPG 2.1 backport ready for jessie, at the usual location: https://people.debian.org/~anarcat/debian/jessie-lts/ I would very much welcome testing of this. There are still some clunky things in there, for example critical lintian warnings I need to fix. I haven't even tried to installed the thing yet, but I figured I would share my work early and get feedback before going on a wild goose chase after the dependencies. Any feedback appreciated. Thanks, A. -- For once you have tasted flight, You will walk the earth with your eyes turned skyward; For there you have been, And there you long to return. - Leonardo da Vinci
Re: updates on the gnupg/enigmail/thunderbird/firefox situation
On 2018-11-11 23:03:07, Emilio Pozuelo Monfort wrote: > On 11/11/2018 15:47, Antoine Beaupré wrote: >> On 2018-11-11 13:21:05, Emilio Pozuelo Monfort wrote: >>> Hi Antoine, >>> >>> On 09/11/2018 20:37, Antoine Beaupré wrote: >>>> On 2018-11-05 16:26:44, Emilio Pozuelo Monfort wrote: >>>>> Hi, >>>>> >>>>> On 30/10/2018 16:46, Antoine Beaupré wrote: >>>>>> Which brings us to Thunderbird (and Firefox) themselves. The last I >>>>>> heard of this is that LLVM was NEW in jessie. I wrote Emilio to see if >>>>>> he needed help on that last week, but haven't got a response. Hopefully >>>>>> all that work will come to fruitition synchronously in a grand fanfare >>>>>> of uploads all working out perfectly in the end. :) >>>>> >>>>> Sorry if I missed your mail. Anyway, here's an update: >>>>> >>>>> LLVM (and the necessary deps) were accepted. Unfortunately I run into some >>>>> trouble while bootstrapping rustc and cargo. I tried some different ways >>>>> and >>>>> finally fixed the first one (bootstrap using upstream binaries). I am >>>>> uploading >>>>> the packages now and will follow up with firefox/thunderbird if all goes >>>>> well. >>>> >>>> Just so I see how fast I should be moving on Enigmail, when do you plan >>>> on uploading Thunderbird? >>> >>> The update is ready, and the blocker was an update to stretch, which has >>> already >>> happen. So I believe we are ready, and this could happen anytime now. >>> >>> However since we don't have a working enigmail, should we delay the update >>> until >>> we do? Given the security issues in thunderbird and the fact that the new >>> version has a Breaks on the old enigmail, I would say that we can go ahead >>> with >>> thunderbird, and enigmail can be fixed asynchronously. However if the >>> update is >>> not too far ahead, we could also delay this a bit longer. >>> >>> Thoughts? >> >> I think we could manage a resolution with Enigmail soon enough, and >> considering how fast those updates were deployed on stretch, i don't >> know if we have a reasonable excuse to delay those in jessie. > > Just to be clear, with 'those' are you referring to thunderbird, i.e. saying > that we should release the update now, and update enigmail asynchronously? > That > is what I think you meant, but perhaps you were referring to enigmail instead, > maybe suggesting that we shouldn't delay the enigmail updates, i.e. we should > block the thunderbird update until the enigmail changes are ready. > > Maybe I'm just being too dense, but if you could clarify which one you meant, > I'd appreciate it. Sorry for being unclear - I meant that the Thunderbird and Firefox updates were deployed quickly, without waiting for Enigmail to be ready. So we should do the same with Jessie (upload FF and TB before Enigmail) especially since we had a long ways to prepare ourselves and indeed have a plan already. So please do go ahead. A. -- We won't have a society if we destroy the environment. - Margaret Mead
Re: updates on the gnupg/enigmail/thunderbird/firefox situation
On 2018-11-11 13:21:05, Emilio Pozuelo Monfort wrote: > Hi Antoine, > > On 09/11/2018 20:37, Antoine Beaupré wrote: >> On 2018-11-05 16:26:44, Emilio Pozuelo Monfort wrote: >>> Hi, >>> >>> On 30/10/2018 16:46, Antoine Beaupré wrote: >>>> Which brings us to Thunderbird (and Firefox) themselves. The last I >>>> heard of this is that LLVM was NEW in jessie. I wrote Emilio to see if >>>> he needed help on that last week, but haven't got a response. Hopefully >>>> all that work will come to fruitition synchronously in a grand fanfare >>>> of uploads all working out perfectly in the end. :) >>> >>> Sorry if I missed your mail. Anyway, here's an update: >>> >>> LLVM (and the necessary deps) were accepted. Unfortunately I run into some >>> trouble while bootstrapping rustc and cargo. I tried some different ways and >>> finally fixed the first one (bootstrap using upstream binaries). I am >>> uploading >>> the packages now and will follow up with firefox/thunderbird if all goes >>> well. >> >> Just so I see how fast I should be moving on Enigmail, when do you plan >> on uploading Thunderbird? > > The update is ready, and the blocker was an update to stretch, which has > already > happen. So I believe we are ready, and this could happen anytime now. > > However since we don't have a working enigmail, should we delay the update > until > we do? Given the security issues in thunderbird and the fact that the new > version has a Breaks on the old enigmail, I would say that we can go ahead > with > thunderbird, and enigmail can be fixed asynchronously. However if the update > is > not too far ahead, we could also delay this a bit longer. > > Thoughts? I think we could manage a resolution with Enigmail soon enough, and considering how fast those updates were deployed on stretch, i don't know if we have a reasonable excuse to delay those in jessie. A. -- To be naive and easily deceived is impermissible, today more than ever, when the prevailing untruths may lead to a catastrophe because they blind people to real dangers and real possibilities. - Erich Fromm
Re: updates on the gnupg/enigmail/thunderbird/firefox situation
On 2018-11-05 16:26:44, Emilio Pozuelo Monfort wrote: > Hi, > > On 30/10/2018 16:46, Antoine Beaupré wrote: >> Which brings us to Thunderbird (and Firefox) themselves. The last I >> heard of this is that LLVM was NEW in jessie. I wrote Emilio to see if >> he needed help on that last week, but haven't got a response. Hopefully >> all that work will come to fruitition synchronously in a grand fanfare >> of uploads all working out perfectly in the end. :) > > Sorry if I missed your mail. Anyway, here's an update: > > LLVM (and the necessary deps) were accepted. Unfortunately I run into some > trouble while bootstrapping rustc and cargo. I tried some different ways and > finally fixed the first one (bootstrap using upstream binaries). I am > uploading > the packages now and will follow up with firefox/thunderbird if all goes well. Just so I see how fast I should be moving on Enigmail, when do you plan on uploading Thunderbird? Thanks! A. -- Nature hides her secret because of her essential loftiness, but not by means of ruse. - Albert Einstein
Re: updates on the gnupg/enigmail/thunderbird/firefox situation
On 2018-11-06 10:57:12, Holger Levsen wrote: > On Tue, Nov 06, 2018 at 02:25:37PM +0700, Daniel Kahn Gillmor wrote: >> On Tue 2018-10-30 11:46:35 -0400, Antoine Beaupré wrote: >> > 5. backport the required GnuPG patchset from stretch to jessie >> fwiw, i don't see how this is going to work, since jessie has only gpg >> 1.4.18 and 2.0.26 -- modern enigmail requires gnupg 2.0.14 at least, so >> that rules out the 1.4 series. And the 2.0 branch has been EOLed and >> unsupported upstream for nearly a year, and represents a significantly >> different codebase than the 2.1/2.2 series. >> >> Or if you are talking about backporting 2.1.x or 2.2.x, that might be a >> different situation; but just backporting the gnupg patches from stretch >> to jessie sounds pretty tough. (i haven't tried though) > > so I'd say this leaves us with two options: a.) getting gnupg 2.1 into > jessie or b.) declaring thunderbird/enigmail unsupported in jessie. i think it should be possible to do a) - as "gpg2" of course. it would require modifications to enigmail to call that binary instead of legacy 1.4, but it might just work without breaking too much stuff as people probably don't rely on gnupg2 in jessie. a. -- Soyons réalistes, faisons l'impossible. - Ernesto "Che" Guevara
Spamassassin 3.4.2 jessie upgrade ready for testing
Hi, As discussed with the SpamAssassin (SA) maintainer, we are following upstream's advice of upgrading to the latest 3.4.2 release in jessie. There's a stable update pending in stretch (#912198) which served as a basis for this upload. I've kept to the strict minimal set of changes but also included critical fixes (like #889501) and ensuring we run the test suite during build (which passes, thankfully). Other unrelated packaging changes were skipped to keep the change minimal. Besides, many of the changes in buster and stretch just don't apply at all in jessie. As long as the update doesn't land in stretch, this should not be updated in jessie either, as the version number proposed here (3.4.2-0+deb8u1) is higher than the one currently in stretch. If the update ends up being refused there, I'll reroll the upload here with a different version number, but it seems to be on track so far. Because SA upstream doesn't follow semantic versionning, the 3.4.0 to 3.4.2 upgrade is deceptively large: 400 files changed, 18289 insertions(+), 13973 deletions(-) About a third (~6000 lines?) of this are rules changes which trickle down to jessie already through sa-update. There's also 8000 lines of diff in the upstream changelog file we can ignore, which leaves us at a more reasonable 4000 lines of diff, although that's still significant. The one change which might break things in deployments is that spamc dropped support for SSLv3. If spamd is updated first, this should not cause any problems. The UPGRADE.gz file has all the details of the upstream changes. Test packages are available in the usual location, along with the debdiff: https://people.debian.org/~anarcat/debian/jessie-lts/ A. -- One of the things the Web teaches us is that everything is connected (hyperlinks) and we all should work together (standards). Too often school teaches us that everything is separate (many different 'subjects') and that we should all work alone. - Aaron Swartz
updates on the gnupg/enigmail/thunderbird/firefox situation
Hi, In the last month, I have work with dkg (in CC) to see how to (ultimately) deal with the end of life of Firefox and Thunderbird ESR as we know them in jessie. He has been hard at work updating GnuPG in stable (#910398) so that Enigmail works with that older version of GnuPG without introducing new security issues. Next step is an update of Enigmail in stable (in #912194) so that it works with the latest Thunderbird 60 upload approved by the security team in mid-september. Because Emilio (also in CC) had claimed the Thunderbird and Firefox package, I figured I would see what would be required to deal with the consequences of such an update in jessie. It seemed obvious an update to at least Enigmail would be required, so I started to drill down into that. I provided code reviews, rubber-ducking and support to dkg in the Enigmail and GnuPG updates, mostly in private, but those are now trickling down in stable updates. Now, unfortunately, I am back here asking you what we should do about those packages again. About a month ago, I offered 5 different options: 1. pretend Enigmail works without changing GnuPG, possibly introducing security issues 2. ship a backport of GnuPG and Enigmail through jessie-sloppy-backports 3. package OpenPGP.js and backport all the way down to jessie 4. remove Enigmail from jessie 5. backport the required GnuPG patchset from stretch to jessie I believe we have now actively researched most of those issues in one way or the other: 1. I verified that Enigmail does indeed has security issues with the current versions of GnuPG, particularly in the Autocrypt mechanism. 2. was never seriously considered 3. I investigated the OpenPGP.js dependency tree and determined it was an impassable forest 4. hasn't been seriously considered yet, as far as I can tell 5. I have helped dkg backport the patches from GnuPG 2.2 to 2.1 for stretch Now I come back to you again for advice. Which path should we take? So far I'm sticking to option #5 above, but I would welcome other opinions. I would suggest we wait for Enigmail and GnuPG to trickle down to stretch and see if any critical issues come out. There are specifically concerns that the backported GnuPG changes might break unrelated software that depend on the brittle dialect GnuPG imposes on its consumers, which *does* change in the backport. I am aware of at least one program (Monkeysphere) which could FTBFS because of a too brittle, build-time, test suite. dkg and I are maintainers on that package and will be able to handle the followup. That should eventually settle Enigmail/GnuPG: either we backport GnuPG patches, or we deem the GnuPG patchset is too invasive to backport to jessie and we remove Enigmail from jessie. The result will be that users will run an outdated version (if they don't notice the package's removed or the announcement) or will run an up to date but possibly insecure version (if they install the Addons version from Mozilla which downloads an arbitrary binary from the network, see #891882). So I think there's a strong incentive in backporting the changes, but we should wait and see what breaks in stable before venturing any further into this dark alley. Which brings us to Thunderbird (and Firefox) themselves. The last I heard of this is that LLVM was NEW in jessie. I wrote Emilio to see if he needed help on that last week, but haven't got a response. Hopefully all that work will come to fruitition synchronously in a grand fanfare of uploads all working out perfectly in the end. :) Voilà. I felt I had been working in the dark on this for a part of October and figured it would be useful to post a refresher on my work. Let me know if that's useful / too long / or have any more questions. A. -- Si les triangles avaient un Dieu, ils lui donneraient trois côtés. - Montesquieu, Lettres persanes
Re: Wheezy update of spamassassin?
On 2018-10-29 09:50:41, Moritz Muehlenhoff wrote: > On Sun, Oct 28, 2018 at 10:19:34PM -0700, Noah Meyerhans wrote: >> On Mon, Oct 22, 2018 at 11:23:50AM -0400, Antoine Beaupré wrote: >> > Ping! Any update here? Do you want us to help with the jessie or stretch >> > update? >> >> I'll be posting a message about the stretch update to debian-release >> shortly. If you want to work on further backporting its update to >> jessie, that is fine with me. The packaging changes for stretch are at >> https://salsa.debian.org/debian/spamassassin/tree/3.4.2-stretch > > Make sure to only release anything after stretch 9.6 has been released, > though. > Otherwise having a higher version in oldstable will cause update problems to > stretch. In any case I'll post a lower version number, if/when I do. Thanks! A. -- Premature optimization is the root of all evil - Donald Knuth
Re: backported gnutls28 3.3.30 packages availabled for jessie LTS
Last call for testing on this, I'll upload the 3.3.30 package on Monday if there's no objection until then. On 2018-10-23 14:00:14, Antoine Beaupré wrote: > Hi, > > After the lengthy discussion[1] regarding the pending security issues in > GnuTLS (CVE-2018-10844, CVE-2018-10845, CVE-2018-10846), I have > determined it might be simpler to just upgrade to the latest upstream > 3.3.x version for which upstream is still providing updates. Upstream > agrees with the approach. This removes 35 Debian-specific, backported > patches and fixes other unrelated bugs. The API/ABI *changes*, but it > only adds *new* symbols so the soname versions do not change. > > [1]: CABY6=0nu1qg9beb5qc-mbzfubmqgxp9dbgnicfupppiwz+o...@mail.gmail.com > > I have uploaded the test package in the usual location here: > > https://people.debian.org/~anarcat/debian/jessie-lts/ > > Direct link to the .changes file: > > https://people.debian.org/~anarcat/debian/jessie-lts/gnutls28_3.3.30-1+deb8u_amd64.changes > > The debdiff is obviously quite large so I haven't audited the whole > diff, which would have basically meant reviewing all the releases > between upstream 3.3.8 and 3.3.0: > > 2151 files changed, 65784 insertions(+), 60661 deletions(-) > > Note that about 3000 lines of those are from debian/patches removals > that were now unnecessary. > > The upstream changelog details all the changes: > > https://gitlab.com/gnutls/gnutls/blob/gnutls_3_3_x/NEWS > > Our branch point was 3.3.8, over four years ago. The latest 3.3.30 > release was last july. > > It should be possible to backport the upstream patches for those issues > as well. But considering the amount of work that represented and how > sensitive the issue is, I felt more confident going with upstream's > recommendation. > > Extensive testing is recommended. The test suite obviously passes here > (otherwise the package does not build) but there might be other problems > that I haven't foreseen. > > Thanks for any feedback. > > A. > -- > Information is not knowledge. Knowledge is not wisdom. > Wisdom is not truth. Truth is not beauty. > Beauty is not love. Love is not music. > Music is the best. - Frank Zappa -- La guerre, c'est le massacre d'hommes qui ne se connaissent pas, au profit d'hommes qui se connaissent mais ne se massacreront pas. - Paul Valéry
Re: Confusing our users - who is supporting LTS?
On 2018-10-26 13:02:57, Thadeu Lima de Souza Cascardo wrote: >> > 5) Is that not true anymore with Extended LTS and CIP? >> >> Sorry, what is not true? #4? If so, I think people should *still* >> install the latest supported Debian release (stable or stretch right >> now) and not LTS or ELTS, when deploying new systems. > > Yeah, not true that Stretch would have a latest term support compared to > any earlier release. So, if one needs something that lasts 12 years, > should one be picking up Stretch, Jessie or Wheezy? "12 years" ... it depends when you start counting. Do you count from the release date of the software? Or "now"? Because if you want 12 years support, jessie, even less so wheezy is not going to help you. >From that perspective, you might stand a better chance of installing *unstable* or *buster* right now if you want the longer support schedule from *right now* because then you'll get the buster release cycle (three years, starting from late 2019 if not 2020), then LTS (two years) and maybe even an extra ELTS (a year or more) slapped on top, which will bring you somewhere somewhere close to 2027. That's 9 years from now, a far cry from your 12 years objective, but it's pretty much the best shot we have. 12-year support cycle is the crazy stuff they do at Solaris, or at least did. Since Oracle bought it, they bumped that up to *twenty* years: https://en.wikipedia.org/wiki/Solaris_(operating_system)#Version_history We're still far away from that goal. And keep in mind the Solaris that is supported there is a very limited operating system when compared with the scope of packages supported in Debian... A. -- La seule excuse de Dieu, c'est qu'il n'existe pas. - Stendhal
Re: Confusing our users - who is supporting LTS?
On 2018-10-26 10:26:09, Thadeu Lima de Souza Cascardo wrote: > On Wed, Oct 24, 2018 at 09:30:46AM +0800, Paul Wise wrote: >> On Wed, Oct 24, 2018 at 4:15 AM Sean Whitton wrote: >> > >> > On Tue 23 Oct 2018 at 05:06PM +0200, Markus Koschany wrote: >> > > >> > > In short: Make it very clear if you want to provide long-term support >> > > for your project. Talk to the LTS team in case you need help. Nobody is >> > > forced to do anything. >> > >> > This is a good idea, but ISTM the assumption should be that the >> > subproject does not participate unless it explicitly says that it does. >> >> This thread started because users have the opposite assumption. So I >> think it would be better to be explicit about support teams and >> timelines. >> >> -- >> bye, >> pabs >> >> https://wiki.debian.org/PaulWise >> > > I am guessing one of the other (incorrect) assumption users might make > is that the "LTS version" is preferred over other versions. That's how > LTS works for Linux and Ubuntu, for example. So, a user would rather > install Ubuntu 18.04 that is supported for 5 years than Ubuntu 18.10, > that is supported for 9 months. The same happens with Linux 4.14 versus > Linux 4.18. I agree that is a concern... > I am not sure it's clear to users that all Debian stable versions would > have Long Term Support, because the releases are not *labeled* as LTS. I > know the wiki says: > > "Debian Long Term Support (LTS) is a project to extend the lifetime of > *all* Debian stable releases to (at least) 5 years." (emphasis mine) > > But I believe the table right below that would still confuse some users > that would understand that Jessie is supported by LTS, while Stretch is > not, even though there is a schedule column there. ... but, well, that is pretty clear isn't it? "All" releases are supported, and "stretch" is explicitely mentioned in the table. I think we've done our part. > Using the LTS term in a slightly different way than the "industry > standard" now means we need to spend a little more effort on users > education. I'm not sure we're using it that differently. But it's true normal stable releases don't immediately get marked as LTS. There are good reasons for that, and those would be very hard to work around. To get more explicit, we can answer your questions one by one: > Should we: > > 1) Start calling the stable releases as LTS releases? No. That would be very confusing, as the stable releases are (to simplify greatly) under the responsability of the security team (ST) and the stable release managers (SRM), not the LTS team. > 2) Say "supported by Security team" versus "supported by Freexian", > instead of just saying "supported by LTS"? Hm... I'm not sure what that refers to or what you're proposing, but LTS releases are *not* supported by the security team, but by the LTS team. > 3) Stop using LTS as a "label" for oldstable releases? I am not sure how that would help anything. :) I do like, however, the idea brought by Jeremy Stanley in a reply to your email of using the "Extended Maintenance" label instead of "Long Term Support" because the latter is usually attached to a *current* release, while the former is seen as an *extension*. But renaming the project seems like a huge undertaking and I'm not sure it would really resolve this conendrum. > 4) Just advise users all the time that they should prefer the latest > stable release, as that is going to have the "latest term support"? Right. So maybe that's a piece that's been missing in our communications, and that could be the reason why people still think they should install jessie cloud images. ;) So maybe we could make some proeminent statement on the LTS and LTS/Using pages in the wiki? > 5) Is that not true anymore with Extended LTS and CIP? Sorry, what is not true? #4? If so, I think people should *still* install the latest supported Debian release (stable or stretch right now) and not LTS or ELTS, when deploying new systems. I think the idea here is that we think Debian rocks. It's solid, stable, and we love it. But we want to support it for even longer than what our volunteer team can deal with right now, so we're hiring a bunch of dedicated fanatics who can figure out how to fit a square peg in a round hole for you. But please don't make us any more square pegs and install Debian normally. Don't break Debian! :) https://wiki.debian.org/DontBreakDebian Thanks! A. -- Work expands so as to fill the time available for its completion. - Parkinson's law
Re: Xen 4.4 updates - request for feedback
On 2018-10-23 14:03:37, Peter Dreuw wrote: > The testing packages are available here: > > https://share.credativ.com/~pdr/xen-test/ One more thing about those... The .deb packages are provided completely without signatures. I understand that the site is protected by HTTPS, but it is customary to actually provide a signed .changes file so that people can double-check the signatures against the web of trust without relying on the third-party CA system. Thanks! A. -- Work expands so as to fill the time available for its completion. - Parkinson's law
Re: Xen 4.4 updates - request for feedback
On 2018-10-24 19:33:45, Peter Dreuw wrote: > Am 24.10.18 um 17:24 schrieb Antoine Beaupré: >> On 2018-10-23 14:03:37, Peter Dreuw wrote: >>> Hello, everyone, >>> >>> I prepared another set of fixes based on the current Xen package on >>> jessie-security (4.4.4lts2-0+deb8u1, DLA-1549). >>> >>> These fixes include >>> >>> CVE-2017-15595 / xsa 240 >>> CVE-2017-15593 / xsa 242 >>> CVE-2017-15592 / xsa 243 >>> CVE-2017-16693 / xsa 244 >>> CVE-2017-17044 / xsa 246 >>> CVE-2017-17045 / xsa 247 >>> CVE-2018-10472 / xsa 258 >>> CVE-2018-10981 / xsa 262 >>> >>> The testing packages are available here: >>> >>> https://share.credativ.com/~pdr/xen-test/ >> I'll be reviewing those diffs shortly, thanks! > Thank you very much. >>> These testing packages are auto generated by our new build system, so the >>> package name is somewhat cryptic as it reflects the date and time of build >>> as well as parts of the git hash it is based on. >>> >>> You can find the repository here: https://github.com/credativ/xen-lts >>> >>> dpkg might tell you about a potential downgrade, but you can ignore this >>> for testing purposes safely. I expect them to be working but I would >>> appreciate some feedback on this version before passing them to the public >>> repository. >> Did you do any kind of smoke testing or is that something that could be >> useful per se? >> >> I always find it tricky to test Xen packages because, well... In what >> environment do you test it? Qemu? Xen? Virtualbox? :) > > I am testing the x86 packages on real hardware and virtual box. But of > course, my hardware spectrum available for this is not to broad. In > general, I make shure that my packages work for me before I would > release them in any way ;) I'm working on integration of Xen fixes into > old versions for a while, now. I already did this on the Xen 4.1 in > Wheezy, fyi. > > The arm packages - which are currently not included in my request for > feedback - are tested on Qemu only. But the arm-only bugs/fixes are > mostly easy to done as the upstream patches apply and upstream does a > great amount of testing. So I consider the work already done not harmful > to the arm systems right now - at least if the x86 tests don't fail ;) That makes sense. Thanks! I won't be doing additional smoke testing then. I encourage others who *have* running Xen systems to give the test packages a shot and will ping a partner here who does. >>> I will head on to the next issues to fix. >> I'm curious: what is your take on XSA-254 and the Meltdown/Spectre >> issues in Xen? Are those fixable? > > I am not sure if this can be done with Xen 4.4 - at least not to a level > of a 100% solution. Looking into the upstream code for e.g. 4.6 there > are many changes that would need to be considered. I am thinking of > this, currently, yes. The same goes to > > > XSA 263 / CVE-2018-3639 > > XSA 267 / CVE-2018-3665 > > XSA 273 / CVE-2018-3620,CVE-2018-3646 > > The upstream fixes for these XSA rely on the XSA 254 work already done. > So getting xsa 263/267/273 fixed would need to adapt much of the work > done for xsa 254. Right. It's a huge challenge and sensitive if not confusing code. >> Should we consider encouraging people to switch to other virtualization >> solutions in LTS/jessie considering the difficulty of mitigation in Xen >> environments? > > Hum, this looks like a need for a political answer ;) Well, you know what they say in french: if you don't care about politics, politics will take care of you. ;) > I honestly don't know if the difficulty level of mitigation in other > old virtualization solutions is really lower. I am going with the assertion that Linux and KVM, in particular, is being fixed in jessie. It may be flawed, but I know a lot of effort was put in resolving those issues in the kernel, for obvious reasons. My impression was that mitigation has been much harder in Xen and that many hosting providers were migrating away. For example, RedHat recommends to migrate to KVM here as well: https://access.redhat.com/solutions/3307791 > An alternative might be offering a version of a more recent Xen package. > AFAIK there is a Xen 4.9 package in Jessie backports already, but this > is not too fresh, I think. I know, LTS users might not like the idea of > shifting to new versions but the spectre/meltdown issue is a class of > its own when it comes to solutions. My comments were not specifically regarding 4.4. From what I understand, those iss
Re: Xen 4.4 updates - request for feedback
On 2018-10-24 11:24:28, Antoine Beaupré wrote: > On 2018-10-23 14:03:37, Peter Dreuw wrote: >> Hello, everyone, >> >> I prepared another set of fixes based on the current Xen package on >> jessie-security (4.4.4lts2-0+deb8u1, DLA-1549). >> >> These fixes include >> >> CVE-2017-15595 / xsa 240 >> CVE-2017-15593 / xsa 242 >> CVE-2017-15592 / xsa 243 >> CVE-2017-16693 / xsa 244 >> CVE-2017-17044 / xsa 246 >> CVE-2017-17045 / xsa 247 >> CVE-2018-10472 / xsa 258 >> CVE-2018-10981 / xsa 262 >> >> The testing packages are available here: >> >> https://share.credativ.com/~pdr/xen-test/ > > I'll be reviewing those diffs shortly, thanks! I've given that a shot and, unfortunately, the actual contents of the patchset goes over my head, so I cannot provide useful feedback on those. When I worked on Xen/qemu before, I was content to just adapt the upstream patches without auditing the fix itself, for what it's worth. So I have reviewed the patches in that context and they generally seem to reflect upstreams' intention, for what that's worth. The only issues I could find were whitespace and shouldn't affect functionality. (In XSA-240 [20c8d60a5c], a comment block present in the upstream patch [0003-x86-dont-wrongly-trigger-linear-page-table-assertion.patch] is missing. Purely cosmetic. Whitespace noise is introduced in 49721ad27a which might make future merges needlessly harder. There's a similar issue in XSA-247 [06d16d9c].) Again, that's assuming that upstream patchsets backport logically into 4.4. Many XSAs have 4.5 patches (or in some cases 4.6) so it's not that big of a leap. Thanks for the hard work! A.
Re: Xen 4.4 updates - request for feedback
On 2018-10-23 14:03:37, Peter Dreuw wrote: > Hello, everyone, > > I prepared another set of fixes based on the current Xen package on > jessie-security (4.4.4lts2-0+deb8u1, DLA-1549). > > These fixes include > > CVE-2017-15595 / xsa 240 > CVE-2017-15593 / xsa 242 > CVE-2017-15592 / xsa 243 > CVE-2017-16693 / xsa 244 > CVE-2017-17044 / xsa 246 > CVE-2017-17045 / xsa 247 > CVE-2018-10472 / xsa 258 > CVE-2018-10981 / xsa 262 > > The testing packages are available here: > > https://share.credativ.com/~pdr/xen-test/ I'll be reviewing those diffs shortly, thanks! > These testing packages are auto generated by our new build system, so the > package name is somewhat cryptic as it reflects the date and time of build as > well as parts of the git hash it is based on. > > You can find the repository here: https://github.com/credativ/xen-lts > > dpkg might tell you about a potential downgrade, but you can ignore this for > testing purposes safely. I expect them to be working but I would appreciate > some feedback on this version before passing them to the public repository. Did you do any kind of smoke testing or is that something that could be useful per se? I always find it tricky to test Xen packages because, well... In what environment do you test it? Qemu? Xen? Virtualbox? :) > I will head on to the next issues to fix. I'm curious: what is your take on XSA-254 and the Meltdown/Spectre issues in Xen? Are those fixable? Should we consider encouraging people to switch to other virtualization solutions in LTS/jessie considering the difficulty of mitigation in Xen environments? Thanks, A. -- The idea that Bill Gates has appeared like a knight in shining armour to lead all customers out of a mire of technological chaos neatly ignores the fact that it was he who, by peddling second-rate technology, led them into it in the first place. - Douglas Adams (1952-2001)
Re: backported gnutls28 3.3.30 packages availabled for jessie LTS
On 2018-10-23 19:26:32, Ben Hutchings wrote: > On Tue, 2018-10-23 at 14:00 -0400, Antoine Beaupré wrote: >> Hi, >> >> After the lengthy discussion[1] regarding the pending security issues in >> GnuTLS (CVE-2018-10844, CVE-2018-10845, CVE-2018-10846), I have >> determined it might be simpler to just upgrade to the latest upstream >> 3.3.x version for which upstream is still providing updates. Upstream >> agrees with the approach. This removes 35 Debian-specific, backported >> patches and fixes other unrelated bugs. The API/ABI *changes*, but it >> only adds *new* symbols so the soname versions do not change. > [...] > > I don't know exactly what gnutls's policy is for stable updates, but > based on a quick look at the NEWS file it seems like these changes are > probably suitable for a stable/LTS update. > > I did spot some incompatible changes in behaviour which might need to > be called out in the Debian changelog or NEWS file, or even reverted, > depending on how many users they might affect: > > ** libgnutls: Refuse to import v1 or v2 certificates that contain > extensions. > > ** libgnutls: ARCFOUR (RC4) is no longer included in the default priorities >list. It has to be explicitly enabled, e.g., with a string like >"NORMAL:+ARCFOUR-128". The previous behavior can be restored using >the flag --with-arcfour128 to configure. > > ** libgnutls: SSL 3.0 is no longer included in the default priorities >list. It has to be explicitly enabled, e.g., with a string like >"NORMAL:+VERS-SSL3.0". The previous behavior can be restored using >the flag --with-ssl3 to configure. > > ** libgnutls: require strict DER encoding for certificates, OCSP requests, > private >keys, CRLs and certificate requests. This backports the already default > behavior >from the 3.5.x branch, in order to reduce issues due to the complexity of > BER rules. Good catches. I should really go through those again with a NEWS.Debian update in mind. One thing they did to fix those 'pseudo-constant time' vulnerabilities is to remove certain algorithms as well, and I don't see those above. So we shold probably warn about that as well. A. -- That's one of the remarkable things about life: it's never so bad that it can't get worse. - Calvin
Re: backported gnutls28 3.3.30 packages availabled for jessie LTS
Ah, and I pushed my changes here: https://salsa.debian.org/debian/gnutls/tree/gnutls28_jessie_3.3.30+ A. -- We should act only in such away that if everyone else acted as we do, we would accept the results. - Emmanuel Kant
backported gnutls28 3.3.30 packages availabled for jessie LTS
Hi, After the lengthy discussion[1] regarding the pending security issues in GnuTLS (CVE-2018-10844, CVE-2018-10845, CVE-2018-10846), I have determined it might be simpler to just upgrade to the latest upstream 3.3.x version for which upstream is still providing updates. Upstream agrees with the approach. This removes 35 Debian-specific, backported patches and fixes other unrelated bugs. The API/ABI *changes*, but it only adds *new* symbols so the soname versions do not change. [1]: CABY6=0nu1qg9beb5qc-mbzfubmqgxp9dbgnicfupppiwz+o...@mail.gmail.com I have uploaded the test package in the usual location here: https://people.debian.org/~anarcat/debian/jessie-lts/ Direct link to the .changes file: https://people.debian.org/~anarcat/debian/jessie-lts/gnutls28_3.3.30-1+deb8u_amd64.changes The debdiff is obviously quite large so I haven't audited the whole diff, which would have basically meant reviewing all the releases between upstream 3.3.8 and 3.3.0: 2151 files changed, 65784 insertions(+), 60661 deletions(-) Note that about 3000 lines of those are from debian/patches removals that were now unnecessary. The upstream changelog details all the changes: https://gitlab.com/gnutls/gnutls/blob/gnutls_3_3_x/NEWS Our branch point was 3.3.8, over four years ago. The latest 3.3.30 release was last july. It should be possible to backport the upstream patches for those issues as well. But considering the amount of work that represented and how sensitive the issue is, I felt more confident going with upstream's recommendation. Extensive testing is recommended. The test suite obviously passes here (otherwise the package does not build) but there might be other problems that I haven't foreseen. Thanks for any feedback. A. -- Information is not knowledge. Knowledge is not wisdom. Wisdom is not truth. Truth is not beauty. Beauty is not love. Love is not music. Music is the best. - Frank Zappa
Re: Confusing our users - who is supporting LTS?
Hi Steve! On 2018-10-23 04:26:18, Steve McIntyre wrote: > 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? TL;DR: Why not just delegate image management to the LTS team once oldstable because LTS just like we do with security? Zobel also provided a good template for the images life cycle which could clarify this on debian-cloud@, which I fully support. I acknowledge this is, indeed, a problem Debian volunteers have sometimes mentioned. It's a broader issue than just the cloud team of course, but if I may, I would like to try and fix that specific issue in itself. I know there's the larger debate of separation of duty and infrastructure, paid-vs-unpaid work and other questions, but I do not think it's productive to fix that particular issue by addressing the larger ones up front, as they seem intractable unless we address specific cases. In this case, it seems to me we have a flawed assumption in the way we handle Debian LTS: we assume people will not actually install it and instead just upgrade machines installed when LTS was "stable". It's a fair assumption in the case of workstations and long-lived, "pet" servers. I know I wouldn't install a new bare-metal server with an unsupported release: I would install stretch, if not buster, not jessie. But in the cloud infrastructure, things are slightly different. The base image isn't as important as the application and/or data that runs on top. In the cloud, we install new "machines" all the time, sometimes as part of CI/CD processes and those machines are not "pets", they are "cattle" and recycled constantly. In that sense, switching the base OS is, paradoxically, a big deal so it actually makes sense to install an older release for newer machines. This is why Travis CI still supports Ubuntu LTS Precise (12.04) and Trusty (14.04), the former which isn't supported by Canonical, and it's missing *two* more recent LTS releases, Xenial (16.04) and Bionic (18.04). So while we haven't taken up the work of managing the debian-installer parts of Debian LTS (because there was no need or demand for it), it seems to me like a fair request that the Debian LTS team should manage the Debian Cloud images once the official support window closes. Just like the security team delegates oldstable to LTS, the cloud team could hand off unsupported images to the LTS team. In a way, just like APT and the normal archive, "cloud images" are just another way to "upgrade" an existing Debian install. It seems like a nice, symmetrical approach to solve the problem: just punt this over to the LTS team. We have some capacity and knowledge. I know I would be happy to work on those images. That's for the expectations part of the question. As for how to clarify this to our users, Martin Zobel-Helas made a good proposal for a workflow of how and when the team updates the images and when they become unsupported. The /etc/motd in the images could mention this, for example and the last build could add a warning pointing to it. If we agree to delegate to the LTS team, the document should also mention that transition. Sorry for the long email, I hope it's useful! a. -- We have to talk about liberating minds as well as liberating society. - Angela Davis
Re: Gnutls investigation and request for advice for Jessie
I am looking at how we diverged from 3.3.30 right now and if it's worth keeping our diversion. Upstream explicitely said they would prefer us to migrate to 3.3.30 so I will the advice seriously. :) a. On 2018-10-22 20:05:52, Ola Lundqvist wrote: > Hi Antoine > > My thinking was that it was easy to check how complicated a backport would > be. If we conclude that it is complicated (patches do not apply and it is > clear that code need to be re-written) then I think we can consider going > for 3.3.30 instead. What do you think? > > // Ola > > On Mon, 22 Oct 2018 at 17:22, Antoine Beaupré > wrote: > >> On 2018-10-18 11:26:04, Ola Lundqvist wrote: >> > Hi >> > >> > Sorry for the late reply. We can consider updating to the 3.3.30, but I >> > suggest you first check how easy it is to backport it. >> >> What do you mean exactly? Backporting it is about as hard as figuring >> out how hard it would be to backport, no? :) >> >> A. >> >> -- >> We will create a civilization of the Mind in Cyberspace. May it be >> more humane and fair than the world your governments have made >> before. >> - John Perry Barlow >> > > > -- > --- Inguza Technology AB --- MSc in Information Technology > / o...@inguza.comFolkebogatan 26\ > | o...@debian.org 654 68 KARLSTAD| > | http://inguza.com/Mobile: +46 (0)70-332 1551 | > \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / > --- -- Omnis enim ex infirmitate feritas est. All cruelty springs from weakness. - Lucius Annaeus Seneca (58 AD)
Re: Wheezy update of spamassassin?
On 2018-09-25 16:03:45, Antoine Beaupré wrote: > On 2018-09-19 19:16:32, Noah Meyerhans wrote: >> On Wed, Sep 19, 2018 at 08:26:28PM +0200, Ola Lundqvist wrote: >>> The Debian LTS team would like to fix the security issues which are >>> currently open in the Wheezy version of spamassassin: >>> https://security-tracker.debian.org/tracker/CVE-2018-11780 >>> https://security-tracker.debian.org/tracker/CVE-2018-11781 >>> https://security-tracker.debian.org/tracker/CVE-2018-15705 >>> >>> Would you like to take care of this yourself? >> >> It's not yet clear how these will even be fixed in stretch, so it may be >> premature to think about wheezy. >> >> At the moment, upstream is advocating strongly for us to move to the >> newly released 3.4.2 upstream version in our stable branches. We're >> considering it, in part because upstream isn't providing a discrete set >> of patches to address the security issues. >> >> I will keep you informed (or worst case, you'll learn via >> debian-security-announce) as to the status of fixes for stable and LTS. > > It would make sense to package 3.4.2 everywhere to me, considering it's > a minor point release. Unfortunately, it seems they bundle quite a bit > of stuff in their point release... :/ > > In the meantime, I'll make a note in the LTS process to hold off while > we figure this out. > > In any case, I'd be happy to help with updates to any suite, since it > will likely be the same across all suites. Ping! Any update here? Do you want us to help with the jessie or stretch update? A. -- Nothing in life is to be feared, it is only to be understood. Now is the time to understand more, so that we may fear less. - Marie Curie
Re: Gnutls investigation and request for advice for Jessie
On 2018-10-18 11:26:04, Ola Lundqvist wrote: > Hi > > Sorry for the late reply. We can consider updating to the 3.3.30, but I > suggest you first check how easy it is to backport it. What do you mean exactly? Backporting it is about as hard as figuring out how hard it would be to backport, no? :) A. -- We will create a civilization of the Mind in Cyberspace. May it be more humane and fair than the world your governments have made before. - John Perry Barlow
Re: Gnutls investigation and request for advice for Jessie
I contacted three parties to try and settle this: * the original authors of the paper * the GnuTLS upstream * the RedHat security team The original authors "still stand behind what is written in the paper" and believe only a constant-time implementation is the proper fix. They point to BoringSSL, OpenSSL and WolfSSL as properly implementing this now, but acknowledge such a fix might impose API breakage, at least in the low-level hash functions. Upstream GnuTLS replied the following: https://gitlab.com/gnutls/gnutls/issues/456#note_105621260 > The solution applied in gnutls 3.3.30 is a mitigation against the > attack published by the authors. As such these CVEs are > addressed. What the authors claim is that these mitigations may not be > sufficient to address a future attack similar in principle to that > one; they indeed have a point but I guess that's with all attacks one > way or another. So backporting these mitigations (or preferably by > updating to 3.3.30) is sufficient to address that vulnerability. A > more general solution is tracked at #503. In other words: that's the solution we got now, use it or wait (possibly for months) for a longer term fix. RedHat security hasn't answered yet, but GnuTLS upstream also replied there: https://bugzilla.redhat.com/show_bug.cgi?id=1582571#c12 > That is, the existing counter-measures present were improved to > protect against this attack. Indeed the paper authors mention that > this may not be sufficient to counter other future attacks, and they > are correct in that. How critical however would be such future > attacks? For that one must note what is the actual impact of this > attack. This type of attacks does only affect the legacy HMAC-based > ciphersuites and only when the gnutls peer does not implement the > encrypt-then-mac construction. That's why the majority of HMAC > ciphersuites are now disabled by default keeping HMAC-SHA1 for > compatibility only. In other words: yes, an attack is still possible, but it's not critical because the impact is smaller. I agree with this analysis: the fix is imperfect, but it's all we got. So I'll be looking at backporting this shortly. Or should we update jessie to 3.3.30 as recommended upstream? There *were* API/ABI changes since 3.3.8, but only new symbols were added - no signatures were changed or removed... A. -- Music gives a soul to the universe, wings to the mind, flight to the imagination and life to everything - Plato
Re: removing enigmail from jessie?
On 2018-09-27 10:51:25, Antoine Beaupré wrote: > So thinking about this again, I see three options: > > 1. Make Enigmail work with GnuPG 2 in Debian and ship the result in > jessie-securtiy. As mentioned above, I think this has huge > implications and risks breaking unrelated software, so it's not > really an option. > > 2. Same as #1, but ship the updates through sloppy backports. We could > then have gnupg2.2 and enigmail live together. It could still break > things, but at least we could say "told you so" and parade around > like it's not our fault. Obviously not ideal either. > > 3. Package the missing dependencies for openpgp.js that make Enigmail > work without GnuPG. That's another big undertaking and it requires > making Javascript packages cross NEW, which is a challenge onto > itself. I've done the little magic thing to list the dependencies > and document this in #787774 but we're far from having this > ready. But at least this would work without damaging unrelated > software. > > 4. Just give up on Enigmail in jessie and remove it from the list of > supported packages. Enigmail is listed in the addons and works well > from there as it's pure Javascript. I'm not sure how that could be > handled: just removing the package from the archive would leave > people without upgrades or a notification that the package is gone > (a recurring problem we should solve, IMHO). >From apo's comment and discussions with one of the enigmail maintainers (dkg), a fifth option came up: 5. backport enigmail with the patches to GPG 2.0. the reason the build-dep version was bumped is there are critical security issues in the way GPG 2 operates under certain circumstances which are used by Enigmail (at least T4017 and T4018 in GnuPG's bts) This seems like the best approach right now. Yes, enigmail works with GPG 2.1 in stretch, but it doesn't mean it's safe. It seems, in fact, particularly vulnerable to arbitrary key injection if I read the above bug reports correctly. == In any case, backporting Enigmail to stretch or jessie is not simple . The problem right now is that Enigmail itself is in a state of flux. The versions compatible with TB 60 are the latest versions and those are, well, in development, to put it mildly. For example, from what I understand, OpenPGP.js is used by Enigmail, but not everywhere: Enigmail still requires a functioning GnuPG installation, which surprised me. [Autocrypt] support is still in development and Debian CI breaks as the test suite fails in some critical code paths which make the current implementation more or less insecure. [Autocrypt]: https://autocrypt.org/ So in short, according to dkg, to get Enigmail working properly, we need to fix the test suite, which involves going deep in some pretty nasty multilayered, vendored and copied Javascript code. The alternative, of course, would be to fork off some Enigmail version and remove Autocrypt support for stable/oldstable. But then we end up living with that fork for a long time as well. So right now I've taken the approach of fixing stuff for unstable and helping dkg deal with this mess. I'll be reviewing his code in the hope we can push an update forward. In the meantime, of course, work on TB60 can proceed - worse case an upload happens before enigmail is ready, like happened in enigmail but obviously it would be better to coordinate this. Whee, what a mess! :) A. -- If you have come here to help me, you are wasting our time. But if you have come because your liberation is bound up with mine, then let us work together.- Aboriginal activists group, Queensland, 1970s
Re: enigmail will break with TB upgrade
On 2018-09-27 17:27:46, Markus Koschany wrote: > Am 27.09.18 um 17:12 schrieb Antoine Beaupré: > [...] >> I wonder what that was all about... >> >> Was the solution for stretch finally to remove enigmail from stable and >> use backports? > > AFAIK he hasn't made a decision yet and I doubt he will use backports > because it's not for fixing bugs in stable. ;-) I can only say for > myself that my private backport of enigmail works on Stretch and I have > only removed the versioned dependency on gnupg2. If it turns out this is > not feasible for Jessie, then we should make an announcement with the > next Firefox update that Firefox addons are no longer supported. However > I am willing to backport ublock-origin and https-everywhere with my > maintainer hat on and I believe this is doable. Yeah, that makes sense for such extensions, but I think gpg is a whole other ballgame. :) A. -- In serious work commanding and discipline are of little avail. - Peter Kropotkin
Re: enigmail will break with TB upgrade
On 2018-09-27 17:05:08, Markus Koschany wrote: > Am 27.09.18 um 04:52 schrieb Antoine Beaupré: > [...] >> Enigmail's work, then, might be better targeted at helping the folks in >> stretch, although I do wonder how we could possibly upgrade GnuPG 2 >> (required to get a new version of Enigmail compatible with TB 60) in >> jessie without causing all sorts of unrelated trouble. Keep in mind that >> Jessie still runs the old 2.0 release instead of the (recommended) 2.1 >> (stretch) or 2.2 (buster) releases. > > Just for the record. I have backported the Buster version of Enigmail to > Stretch and it works simply by removing the versioned dependency on > gnupg2. So far I haven't noticed any issues. But stretch has GnuPG 2.1 and it's the default gpg binary. jessie will be a whole other story... dkg was saying the reason Enigmail used openpgp.js is because gpg was outdated somehow on some platforms: * instead, i realized that the OpenPGP.js node package was only needed by enigmail for a few things, in particular to avoid needing a newer version of GnuPG. * there were a few small changes that needed to be made to GnuPG to make enigmail pass its test suites properly without OpenPGP.js, so i got them made upstream in GnuPG. * then i stripped OpenPGP.js from enigmail, and bumped enigmail's dependency on GnuPG. Source: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909000 I wonder what that was all about... Was the solution for stretch finally to remove enigmail from stable and use backports? A. -- Le pouvoir n'est pas à conquérir, il est à détruire - Jean-François Brient, de la servitude moderne
removing enigmail from jessie?
On 2018-09-26 22:52:01, Antoine Beaupré wrote: > So one problem we have with maintaining the post-XUL programs like > Thunderbird and Firefox is not only backporting the build toolchain, but > also the leaf dependencies. > > Enigmail, for example, is broken since Thunderbird 60 landed in stretch: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909000 > > Fixing this in stretch will be a significant challenge, let alone in > jessie. I wonder how we want to approach this. > > Presumably, Emilio, while working on Firefox, would also backport the > toolchain necessary for Thunderbird, is that correct? > > Enigmail's work, then, might be better targeted at helping the folks in > stretch, although I do wonder how we could possibly upgrade GnuPG 2 > (required to get a new version of Enigmail compatible with TB 60) in > jessie without causing all sorts of unrelated trouble. Keep in mind that > Jessie still runs the old 2.0 release instead of the (recommended) 2.1 > (stretch) or 2.2 (buster) releases. So thinking about this again, I see three options: 1. Make Enigmail work with GnuPG 2 in Debian and ship the result in jessie-securtiy. As mentioned above, I think this has huge implications and risks breaking unrelated software, so it's not really an option. 2. Same as #1, but ship the updates through sloppy backports. We could then have gnupg2.2 and enigmail live together. It could still break things, but at least we could say "told you so" and parade around like it's not our fault. Obviously not ideal either. 3. Package the missing dependencies for openpgp.js that make Enigmail work without GnuPG. That's another big undertaking and it requires making Javascript packages cross NEW, which is a challenge onto itself. I've done the little magic thing to list the dependencies and document this in #787774 but we're far from having this ready. But at least this would work without damaging unrelated software. 4. Just give up on Enigmail in jessie and remove it from the list of supported packages. Enigmail is listed in the addons and works well from there as it's pure Javascript. I'm not sure how that could be handled: just removing the package from the archive would leave people without upgrades or a notification that the package is gone (a recurring problem we should solve, IMHO). I'm leaning towards working a bit towards #3 since that would benefit everyone in the long term, but I suspect the endgame will be #4: removal. Comments? -- Men are taught to apologize for their weaknesses, women for their strengths. - Lois Wyse
enigmail will break with TB upgrade
So one problem we have with maintaining the post-XUL programs like Thunderbird and Firefox is not only backporting the build toolchain, but also the leaf dependencies. Enigmail, for example, is broken since Thunderbird 60 landed in stretch: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909000 Fixing this in stretch will be a significant challenge, let alone in jessie. I wonder how we want to approach this. Presumably, Emilio, while working on Firefox, would also backport the toolchain necessary for Thunderbird, is that correct? Enigmail's work, then, might be better targeted at helping the folks in stretch, although I do wonder how we could possibly upgrade GnuPG 2 (required to get a new version of Enigmail compatible with TB 60) in jessie without causing all sorts of unrelated trouble. Keep in mind that Jessie still runs the old 2.0 release instead of the (recommended) 2.1 (stretch) or 2.2 (buster) releases. So before anyone jumps both feet into patching enigmail for whatever issues are pending there, this should be taken into account. A. -- Growth for the sake of growth is the ideology of the cancer cell. - Edward Abbey
Re: CVE-2018-14624 - testing 389-ds-base update
On 2018-09-15 12:04:02, Hugo Lefeuvre wrote: > Hi, > > I have just prepared a Jessie security update for 389-ds-base, addressing > CVE-2018-14624. I will go through the test procedure myself, however I am > not a 389-ds user, so it might be good if someone more experienced with > this LDAP server could double check the update before upload. I have no experience with that LDAP server either - I have only used OpenLDAP in the past. But that experience did allow me to smoke-test your packages and they can live through an upgrade without crashing on restart and ldapsearch still works. So I would say it's good enough for now. A. -- The history of any one part of the earth, like the life of a soldier, consists of long periods of boredom and short periods of terror. - British geologist Derek V. Ager
Re: Wheezy update of spamassassin?
On 2018-09-19 19:16:32, Noah Meyerhans wrote: > On Wed, Sep 19, 2018 at 08:26:28PM +0200, Ola Lundqvist wrote: >> The Debian LTS team would like to fix the security issues which are >> currently open in the Wheezy version of spamassassin: >> https://security-tracker.debian.org/tracker/CVE-2018-11780 >> https://security-tracker.debian.org/tracker/CVE-2018-11781 >> https://security-tracker.debian.org/tracker/CVE-2018-15705 >> >> Would you like to take care of this yourself? > > It's not yet clear how these will even be fixed in stretch, so it may be > premature to think about wheezy. > > At the moment, upstream is advocating strongly for us to move to the > newly released 3.4.2 upstream version in our stable branches. We're > considering it, in part because upstream isn't providing a discrete set > of patches to address the security issues. > > I will keep you informed (or worst case, you'll learn via > debian-security-announce) as to the status of fixes for stable and LTS. It would make sense to package 3.4.2 everywhere to me, considering it's a minor point release. Unfortunately, it seems they bundle quite a bit of stuff in their point release... :/ In the meantime, I'll make a note in the LTS process to hold off while we figure this out. In any case, I'd be happy to help with updates to any suite, since it will likely be the same across all suites. A. -- There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. - C.A.R. Hoare
Re: git-annex security update ready for testing and review
On 2018-09-06 15:42:41, Joey Hess wrote: > Antoine Beaupré wrote: >> I'm now more confident the patchset is complete. There are one tiny bit >> I'm still slightly unsure of. In Command.Reinject.perform, there was a >> `boolSystem "mv"` call lying around that was turned into a `moveFile` >> some time between the jessie version and 2fb3722ce. I figured this was >> the last instance of such an "mv" call and that moveFile does what it's >> supposed to do in the jessie version. So to avoid any compiler mishaps, >> I figured I would just use moveFile there but I'm not certain of the >> implications. > > I don't think this change was strictly necessary, but I do think it's correct. > >> I'm also wondering if there are reproducers for those vulnerabilities so >> that I can test the new packages to see if they actually fix the >> problems. > > No, I don't have any. You can test downloads from localhost and non-http > url schemes to make sure they're blocked. > >> So I've uploaded the test packages to my repository again: >> >> https://people.debian.org/~anarcat/debian/jessie-lts/ >> >> This time, testing would be greatly appreciated. And of course, a review >> of the patchset would be great as well. > > I've looked over the patchset and nothing stands out to me as a problem, > but it is of course a big patchset against a very old version so it > would be easy to miss something. Thanks so much for the review (and the quote on your devblog, btw! :). I understand it's a huge patch and I'm of course not asking for any warranties. Just having an extra pair of eyes on this is great in any case. Cheers! A. -- The fundamental cause of the trouble is that in the modern world the stupid are cocksure while the intelligent are full of doubt. - Bertrand Russell, The Triumph of Stupidity, 1933
Re: twitter-bootstrap / CVE-2018-14040 / CVE-2018-14041 / CVE-2018-14042
On 2018-09-02 17:08:09, Brian May wrote: > Antoine Beaupré writes: > >> What do you think? Should we push this forward? > > I am somewhat concerned that by fixing this we might be breaking > something. Even if it is 100% broken behaviour, maybe some application > depends on this? > > Is the potential attack bad enough to justify potential breakage? I am > not absolutely convinced. Well there *are* probably some XSS left. The solution would be similar to the one I did in the DLA with little or no breakage. A. -- The class which has the power to rob upon a large scale has also the power to control the government and legalize their robbery. - Eugene V. Debs
Re: Gnutls investigation and request for advice for Jessie
On 2018-08-31 16:18:39, Antoine Beaupré wrote: > On 2018-08-31 21:30:14, Ola Lundqvist wrote: >> Hi Antoine >> >> Thank you for the input this is valuable. I have some comments below. >> >> On Fri, 31 Aug 2018 at 21:03, Antoine Beaupré >> wrote: >>> >>> On 2018-08-31 13:29:29, Ola Lundqvist wrote: >>> > Hi all LTS contributors >>> > >>> > My question is whether removing default ciphers and introducing new >>> > options is acceptable so late in the release cyckle. My assumption is >>> > no, but let me know if you have another opinion. More details below. >>> >>> A priori, I think it is if it fixes serious security vulnerabilities and >>> there is no easier way to do so. >> >> I'm not so sure this is a serious issue as it is only exploitable in a >> rather uncommon case, that is when Encrypt-then-MAC (RFC7366) is >> unsupported by the peer. >> Most software do have that support as I understand it. > > That's the crucial part, I guess. :) I am not sure. The paper actually makes that claim which seems important: > The “Encrypt-then-MAC” countermeasure from RFC 7366 is supported in > mbed TLS and GnuTLS, but requires client-side support and has seen > little uptake elsewhere (e.g. neither Firefox nor Chrome supports the > EtM extension). In other words, EtM is not well supported in clients at all, and just forcing that mode does not seem to be a good strategy for mitigation. The paper does refer to a good source for TLS adoption numbers. https://notary.icsi.berkeley.edu/ With that as a source, it says that 10% of TLS traffic is still in CBC mode. The site does not load here so I cannot make further research, unfortunately. [...] > If you are unsure about updates, upload a test package somewhere and ask > people for feedback. I do it all the time and it actually works, if you > give people time (sometimes a week or more). For an update as critical, > it would certainly be warranted. Also, I would be happy to review patches and packages you propose, unless that wasn't clear already. :) >>> It seems that upstream did the right thing here and backported a bunch >>> of stuff for us already - it'd be too bad to waste that effort and skip >>> those CVEs. ;) >> >> :-D on the other hand maybe we break backwards compatibility. If it >> wasn't for the backwards compatibility I would not have asked. :-) > > Yeah, I guess I don't know what's in those updates exactly, that's a > good point. Another important point I found while (finally) reading the whole paper is that: > However, we believe that the GnuTLS code is still vulnerable to > variants of the attacks presented in our paper due to its > padding-dependent memory accesses. We notified the GnuTLS team of our > concerns about this on June 13th 2018. Our understanding is that the > GnuTLS team does not plan to address the issues, but prefers to > promote the use of Encrypt-then-MAC (as specified in RFC 7366) when > legacy cipher suites are required. Considering this and the lack of EtM support in the wild, I'm starting to seriously question the claims of the GnuTLS upstream. It does not seem like they really have fixed this at all, again, I should add. I'm sorry I am not bringing a more positive note here, but it does seem like things are a mess on GnuTLS' side. Maybe we should consider asking upstream for more information about their stance on the paper author's claims to get a clearer picture. Finally, the paper mentions that the Red Hat security team issued those CVEs, so they might have something up their sleeve as well, although a look at their Bugzilla does not yield anything conclusive. Good luck! A. -- If it's important for you, you'll find a way. If it's not, you'll find an excuse. - Unknown
Re: Gnutls investigation and request for advice for Jessie
On 2018-08-31 21:30:14, Ola Lundqvist wrote: > Hi Antoine > > Thank you for the input this is valuable. I have some comments below. > > On Fri, 31 Aug 2018 at 21:03, Antoine Beaupré wrote: >> >> On 2018-08-31 13:29:29, Ola Lundqvist wrote: >> > Hi all LTS contributors >> > >> > My question is whether removing default ciphers and introducing new >> > options is acceptable so late in the release cyckle. My assumption is >> > no, but let me know if you have another opinion. More details below. >> >> A priori, I think it is if it fixes serious security vulnerabilities and >> there is no easier way to do so. > > I'm not so sure this is a serious issue as it is only exploitable in a > rather uncommon case, that is when Encrypt-then-MAC (RFC7366) is > unsupported by the peer. > Most software do have that support as I understand it. That's the crucial part, I guess. :) I am not sure. [...] >> > Upstream do in fact not even plan to do this as the problem only occur >> > in the following cases: >> > - CBC cipher >> > - If Encrypt-then-MAC (RFC7366) is unsupported by the peer >> > >> > Instead upstream have done the following: >> > 1) Introduced a new option to enforce Encrypt-then-MAC (for CVE-2018-10846) >> > 2) Do a fix with SHA384 (for CVE-2018-10845) >> > 3) Remove SHA256 and SHA384 from the default MAC ciphers (for >> > CVE-2018-10844 and CVE-2018-10845) >> > 4) A try to fix the problem (CVE-2018-10844 and potentially CVE-2018-10845) >> > >> > 1: I do not think we can do 1 such late in the release cycle. I mean >> > new options now would be rather pointless. I will mark CVE-2018-10846 >> > as ignored due to this. Or do you think new options is ok also in >> > Jessie? >> >> I looked at the upstream patch (MR#657) for this and it doesn't look >> that invasive. According to GitLab, it is "21 files with 738 additions >> and 148 deletions", which seems fairly small considering the scope of >> the change: >> >> https://gitlab.com/gnutls/gnutls/merge_requests/657.patch > > I agree on that. But introducing an option will not help in most cases > that use gnutls. I mean gnutls is used in most cases as a library and > unless the other software is changed then there is no use of > introducing the option. That's true! I'm not sure how to deal with that... I guess it means library users need to do the right thing then? Unless they mess around with cipher lists the way charybdis does? [...] >> This, again, is also part of the larger fix in MR#657. >> >> Combined, those last two patches make about +- 50 lines of diff, >> compared to the 700+ lines of diff for the larger merge request. But do >> consider that a large part of MR#657 (+400 lines) is the introduction of >> tests/tls-force-etm.c, a standalone file which shouldn't cause conflicts >> at the very least. >> >> > I think I should do 2 and 4, but not 1 and 3. >> > >> > What do you think? If I do not hear any objections I'll do so. >> >> I would give it a shot and try to backport the whole thing. I would also >> carefully look at the 3.3.x series to see if there's an official commit >> shipping those. At first glance, it does look like a release was made on >> all branches, including a 3.3.30 release that bundles some of those >> patches. > > But not the default cipher removal, right? Actually, looking at the NEWS file, they *did* remove the ciphers from the defaults list as well. >> In fact, I'd be tempted to seriously consider upgrading to that upstream >> release after comparing our changelog with theirs to see if there's >> anything missing either side... > > That is another way. I'm not so comfortable with doing that > considering that I broke some software I did that with a library > package. I do not remember what library it was now but some browser > did not work after that. You mean the NSS library and #843624? :) That was a hairy issue and it affected an unsupported package (chromium). I don't think you should stop from working on difficult package because of one difficulty. If anything, that was a learning experience and you are now *more* qualified to deal with such packages now. ;) If you are unsure about updates, upload a test package somewhere and ask people for feedback. I do it all the time and it actually works, if you give people time (sometimes a week or more). For an update as critical, it would certainly be warranted. >> It seems that upstream did the right thing here and backported a bunch >> of stuff for us already - it'd be too bad to waste that effort and skip >> those CVEs. ;) > > :-D on the other hand maybe we break backwards compatibility. If it > wasn't for the backwards compatibility I would not have asked. :-) Yeah, I guess I don't know what's in those updates exactly, that's a good point. > Again thank you for the input. Glad to be of service! A.
Re: tiff / CVE-2018-15209
On 2018-08-29 12:24:30, Brian May wrote: > Antoine Beaupré writes: > >> Brian, are you sure you're getting those failures in jessie? Which >> architecture? Here my tests were done in a VirtualBox VM using an up to >> date Debian jessie amd64 box. > > My tests were done in a schroot. Not sure if I used i386 or amd64 now. Well, as I can't reproduce any issue at all with this, I've left it as N/A for jessie. A. -- Secrecy is the keystone to all tyranny. Not force, but secrecy and censorship. - Robert A. Heinlein
Re: twitter-bootstrap / CVE-2018-14040 / CVE-2018-14041 / CVE-2018-14042
On 2018-08-29 12:23:54, Brian May wrote:
> Antoine Beaupré writes:
>
>> On 2018-08-08 17:35:52, Brian May wrote:
>>> If I got this right, we cannot use $(xyz) unless the value of xyz is
>>> trusted. Otherwise executing $(xyz) can result in the execution of code
>>> if xyz is something like "". This
>>> happens immediately, and even if you don't use the return value.
>>
>> I am a bit puzzled as to how this attack works, but I'm ready to accept
>> that as yet another jQuery excentricity. :)
>
> So my understanding only, $(...) has been overloaded and has a number of
> distinct uses.
>
> You can use it to look up a value, e.g.:
>
> $("#myid")
>
> You can use it to create a DOM element:
>
> $("ABC")
>
> Or:
>
> $("")
>
> This will not only create the dom element, and try to preload the
> image. When this fails, the onerror hook is called.
>
> You could also use it to wrap a JS DOM element in a jquery selector, but
> this use isn't so relevant here.
Right, of course. That makes sense, somewhat.
> The problem occurs as this code does lookups on untrusted values like:
>
> $(untrusted_input)
>
> The problem being if untrusted_input can change the mode from "lookup"
> to "create" which in turn assumes that the data passed is trusted.
>
> I think the real problem here is poor jquery API, however I doubt this
> is going to change anytime soon as this would break everything that uses
> jquery.
Indeed. As far as Bootstrap is concerned, they are just going away from
that API at this point and use native lookups without side-effects:
https://github.com/twbs/bootstrap/issues/26643
But unfortunately, that work was done only in Bootstrap 4, which is not
even in Debian yet.
There are, unfortunately, a non-trivial number of packages depending on
bootstrap (even v2!) in the archive still, otherwise I would propose to
just remove the damn things and get it over with.
I guess the proper process here would be to actually test a few
instances to see if we are still vulnerable and open issues (CVE?
upstream?) to track those.
What do you think? Should we push this forward?
A.
--
Freedom of speech is a principal pillar of a free government; when
this support is taken away, the constitution of a free society is
dissolved, and tyranny is erected on its ruins.
- Benjamin Franklin, 1737
