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
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 >
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.
[SECURITY] [DLA 1669-1] libreoffice security update
Package: libreoffice Version: 1:4.3.3-2+deb8u12 CVE ID : CVE-2018-16858 Alex Infuehr discovered a directory traversal vulnerability which could result in the execution of Python script code when opening a malformed document. For Debian 8 "Jessie", this problem has been fixed in version 1:4.3.3-2+deb8u12. We recommend that you upgrade your libreoffice packages. Further information about Debian LTS security advisories, how to apply these updates to your system and frequently asked questions can be found at: https://wiki.debian.org/LTS -- signature.asc Description: PGP signature
Accepted libreoffice 1:4.3.3-2+deb8u12 (source amd64 all) into oldstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 07 Feb 2019 14:24:28 -0500 Source: libreoffice Binary: libreoffice libreoffice-l10n-za libreoffice-l10n-in libreoffice-core libreoffice-common libreoffice-java-common libreoffice-writer libreoffice-calc libreoffice-impress libreoffice-draw libreoffice-math libreoffice-base-core libreoffice-base libreoffice-style-crystal libreoffice-style-oxygen libreoffice-style-tango libreoffice-style-hicontrast libreoffice-style-sifr libreoffice-style-galaxy libreoffice-gtk libreoffice-gtk3 libreoffice-gnome python-uno python3-uno libreoffice-officebean openoffice.org-dtd-officedocument1.0 libreoffice-script-provider-python libreoffice-script-provider-bsh libreoffice-script-provider-js libreoffice-pdfimport libreoffice-avmedia-backend-gstreamer libreoffice-avmedia-backend-vlc libreoffice-sdbc-firebird libreoffice-sdbc-hsqldb libreoffice-base-drivers libreoffice-l10n-af libreoffice-l10n-ar libreoffice-l10n-as libreoffice-l10n-ast libreoffice-l10n-be libreoffice-l10n-bg libreoffice-l10n-bn libreoffice-l10n-br libreoffice-l10n-bs libreoffice-l10n-ca libreoffice-l10n-cs libreoffice-l10n-cy libreoffice-l10n-da libreoffice-l10n-de libreoffice-l10n-dz libreoffice-l10n-el libreoffice-l10n-en-gb libreoffice-l10n-en-za libreoffice-l10n-eo libreoffice-l10n-es libreoffice-l10n-et libreoffice-l10n-eu libreoffice-l10n-fa libreoffice-l10n-fi libreoffice-l10n-fr libreoffice-l10n-ga libreoffice-l10n-gd libreoffice-l10n-gl libreoffice-l10n-gu libreoffice-l10n-he libreoffice-l10n-hi libreoffice-l10n-hr libreoffice-l10n-hu libreoffice-l10n-id libreoffice-l10n-is libreoffice-l10n-it libreoffice-l10n-ja libreoffice-l10n-ka libreoffice-l10n-kk libreoffice-l10n-km libreoffice-l10n-ko libreoffice-l10n-kmr libreoffice-l10n-lt libreoffice-l10n-lv libreoffice-l10n-mk libreoffice-l10n-mn libreoffice-l10n-ml libreoffice-l10n-mr libreoffice-l10n-nb libreoffice-l10n-ne libreoffice-l10n-nl libreoffice-l10n-nn libreoffice-l10n-nr libreoffice-l10n-nso libreoffice-l10n-oc libreoffice-l10n-om libreoffice-l10n-or libreoffice-l10n-pa-in libreoffice-l10n-pl libreoffice-l10n-pt libreoffice-l10n-pt-br libreoffice-l10n-ro libreoffice-l10n-ru libreoffice-l10n-rw libreoffice-l10n-si libreoffice-l10n-sk libreoffice-l10n-sl libreoffice-l10n-sr libreoffice-l10n-ss libreoffice-l10n-st libreoffice-l10n-sv libreoffice-l10n-ta libreoffice-l10n-te libreoffice-l10n-tg libreoffice-l10n-th libreoffice-l10n-tn libreoffice-l10n-tr libreoffice-l10n-ts libreoffice-l10n-ug libreoffice-l10n-uk libreoffice-l10n-uz libreoffice-l10n-ve libreoffice-l10n-vi libreoffice-l10n-xh libreoffice-l10n-zh-cn libreoffice-l10n-zh-tw libreoffice-l10n-zu libreoffice-presenter-console libreoffice-presentation-minimizer libreoffice-emailmerge libreoffice-l10n-ku libreoffice-help-en-us libreoffice-help-ca libreoffice-help-cs libreoffice-help-da libreoffice-help-de libreoffice-help-dz libreoffice-help-el libreoffice-help-en-gb libreoffice-help-es libreoffice-help-et libreoffice-help-eu libreoffice-help-fi libreoffice-help-fr libreoffice-help-gl libreoffice-help-hi libreoffice-help-hu libreoffice-help-it libreoffice-help-ja libreoffice-help-km libreoffice-help-ko libreoffice-help-nl libreoffice-help-om libreoffice-help-pl libreoffice-help-pt libreoffice-help-pt-br libreoffice-help-ru libreoffice-help-sk libreoffice-help-sl libreoffice-help-sv libreoffice-help-tr libreoffice-help-vi libreoffice-help-zh-cn libreoffice-help-zh-tw uno-libs3 ure browser-plugin-libreoffice libreoffice-ogltrans libreoffice-wiki-publisher libreoffice-report-builder libreoffice-report-builder-bin fonts-opensymbol libreoffice-dbg uno-libs3-dbg ure-dbg libreoffice-dev libreoffice-dev-doc libreoffice-kde libreoffice-sdbc-postgresql libreoffice-mysql-connector libreoffice-evolution libreoffice-subsequentcheckbase libreoffice-librelogo Architecture: source amd64 all Version: 1:4.3.3-2+deb8u12 Distribution: jessie-security Urgency: high Maintainer: Debian LibreOffice Maintainers Changed-By: Antoine Beaupré Description: browser-plugin-libreoffice - office productivity suite -- Mozilla plugin fonts-opensymbol - OpenSymbol TrueType font libreoffice - office productivity suite (metapackage) libreoffice-avmedia-backend-gstreamer - GStreamer backend for LibreOffice libreoffice-avmedia-backend-vlc - VLC backend for LibreOffice libreoffice-base - office productivity suite -- database libreoffice-base-core - office productivity suite -- shared library libreoffice-base-drivers - Database connectivity drivers for LibreOffice libreoffice-calc - office productivity suite -- spreadsheet libreoffice-common - office productivity suite -- arch-independent files libreoffice-core - office productivity suite -- arch-dependent files libreoffice-dbg - office productivity suite -- debug symbols libreoffice-dev - office productivity suite -- SDK libreoffice-dev-doc - office productivity suite -- SDK documentation
Accepted libarchive 3.1.2-11+deb8u7 (source amd64) into oldstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 07 Feb 2019 13:04:01 -0500 Source: libarchive Binary: libarchive-dev libarchive13 bsdtar bsdcpio Architecture: source amd64 Version: 3.1.2-11+deb8u7 Distribution: jessie-security Urgency: medium Maintainer: Debian Libarchive Maintainers Changed-By: Antoine Beaupré Description: bsdcpio- Implementation of the 'cpio' program from FreeBSD bsdtar - Implementation of the 'tar' program from FreeBSD libarchive-dev - Multi-format archive and compression library (development files) libarchive13 - Multi-format archive and compression library (shared library) Changes: libarchive (3.1.2-11+deb8u7) jessie-security; urgency=medium . * Non-maintainer upload by the LTS Security Team. * Fix CVE-2019-119: Out-of-bounds Read vulnerability in 7zip decompression, that can result in a crash (denial of service, CWE-125) * Fix CVE-2019-120: vulnerability in ISO9660 parser that can result in DoS by infinite loop (CWE-835) Checksums-Sha1: 591696e41f6e74cd3721f391bb5cc8c0a6215aac 1982 libarchive_3.1.2-11+deb8u7.dsc 58dd6b879a00e0292e128caccd8c923e6c26892a 42656 libarchive_3.1.2-11+deb8u7.debian.tar.xz 05011a5906a3b7a20dcfd94a91bed6fdbc6ea157 434828 libarchive-dev_3.1.2-11+deb8u7_amd64.deb 4e79927ac7e02ae0c42aec5207de3d188872629a 271150 libarchive13_3.1.2-11+deb8u7_amd64.deb e31ef34bfcafaa1e56da1b432789ee666cd646ce 54646 bsdtar_3.1.2-11+deb8u7_amd64.deb 5f6fe0b750c49ae4bd51011be80af36b795f22c5 40200 bsdcpio_3.1.2-11+deb8u7_amd64.deb Checksums-Sha256: 36e8237ba3e554ed03e57a984f3bda296e40280671c9fbee7bc92aa181e3a5a8 1982 libarchive_3.1.2-11+deb8u7.dsc 188786a51ba927b8d498cb92c0939d66b771e7c5e974d399bddb6254c8f135b7 42656 libarchive_3.1.2-11+deb8u7.debian.tar.xz 3b5f07fa874e4b4d3abf4707e4f63cd006a9d1db2b4100283de74ff7989fd828 434828 libarchive-dev_3.1.2-11+deb8u7_amd64.deb 279f990382b6074d302913a87f48cad8ede1df7a390945c029b23015a5b7c2df 271150 libarchive13_3.1.2-11+deb8u7_amd64.deb 2a9edc94203a427966a53c79dacc99021ad961a2e8c478b16ff3fe78a6586af6 54646 bsdtar_3.1.2-11+deb8u7_amd64.deb b149852b52a13cc9c991e9d74f969055cec0bcc7fe152351253f7009d43c368a 40200 bsdcpio_3.1.2-11+deb8u7_amd64.deb Files: 832cc52c0a02dfc04c6fc780f116529f 1982 libs optional libarchive_3.1.2-11+deb8u7.dsc 3cf3372dd630ec4c6d9baa74d4b55fc2 42656 libs optional libarchive_3.1.2-11+deb8u7.debian.tar.xz a20c5c0601a23a475e4b70ce0a6e3bfa 434828 libdevel optional libarchive-dev_3.1.2-11+deb8u7_amd64.deb ae1b3423cfe5d69c7dda16bac6ae017d 271150 libs optional libarchive13_3.1.2-11+deb8u7_amd64.deb 3baee0842be12f726a6ca50d1fa5dfa5 54646 utils optional bsdtar_3.1.2-11+deb8u7_amd64.deb 0584c893887c8865e4df4480cf02e021 40200 utils optional bsdcpio_3.1.2-11+deb8u7_amd64.deb -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEexZCBNCWcjsBljWrPqHd3bJh2XsFAlxcfFkACgkQPqHd3bJh 2XsUwwf/Z056V8Dm6oHnsr0pyh8suGwsDvjfdtzGm+5763rt5jr5aaAxCKoWn4a/ mT9pNV+lhMnsM4/v2Mdx5C/FFfZdxeBMSWgptDbBmy1ABdXFVUcMdUMpa4HXwFxq 4gzQ5dtWRid1m4tmWx1rSVszWgDzWQ+KDnDHhGo9XXSpHsm4dLoQVLNQUuW1fkoO gG7u99K1RCwvcJqZZ74nSA/UBvS6LXFnrtjB8o6bOhC4J6MO4O+MGWe9XncPUKo5 mZ94mRHLkCxQ+u/9j3gx5VJamEEvaywsWVkjCoURnLzGye9eo3seRVWqTCusDZNU dvhrI8YErznBrtERdIQSXgV/bLwkIg== =N0VG -END PGP SIGNATURE-
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
[SECURITY] [DLA 1665-1] netmask security update
Package: netmask Version: 2.3.12+deb8u1 Debian Bug : 921565 A buffer overflow was found in netmask which would crash when called with arbitrarily long inputs. For Debian 8 "Jessie", this problem has been fixed in version 2.3.12+deb8u1. We recommend that you upgrade your netmask packages. Further information about Debian LTS security advisories, how to apply these updates to your system and frequently asked questions can be found at: https://wiki.debian.org/LTS signature.asc Description: PGP signature
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"
[SECURITY] [DLA 1660-1] rssh security update
Package: rssh Version: 2.3.4-4+deb8u2 CVE ID : CVE-2019-3463 CVE-2019-3464 More vulnerabilities were found by Nick Cleaton in the rssh code that could lead to arbitrary code execution under certain circumstances. CVE-2019-3463 reject rsync --daemon and --config command-line options; arbitrary command execution CVE-2019-3464 prevent popt to load a ~/.popt configuration file, leading to arbitrary command execution For Debian 8 "Jessie", these problems have been fixed in version 2.3.4-4+deb8u2. We recommend that you upgrade your rssh packages. Further information about Debian LTS security advisories, how to apply these updates to your system and frequently asked questions can be found at: https://wiki.debian.org/LTS -- signature.asc Description: PGP signature
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 >
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
[SECURITY] [DLA-1657-1] debian-security-support enigmail end of life
Package: debian-security-support Version: 2019.02.01~deb8u1 debian-security-support, the Debian security support coverage checker, has been updated in jessie. This marks the end of life of the Enigmail package in jessie. After many months of work to try backporting the various changes and fixes required to ensure a secure Enigmail package compatible with the newest version of Thunderbird now shipped in jessie, it is the LTS team's opinion that the changes are too intrusive to ensure the stability of the distribution as a whole. While Enigmail is still available on addons.mozilla.org, we do not recommend that package is used, as downloads and executes arbitrary binaries from the internet without the user's knowledge. It also doesn't respect's Debian commitment to free software, in that it is not buildable from source. We instead recommend you upgrade workstations needing Enigmail to Debian stretch where proper updates are available. Further information about Debian LTS security advisories, how to apply these updates to your system and frequently asked questions can be found at: https://wiki.debian.org/LTS signature.asc Description: PGP signature
Accepted debian-security-support 2019.02.01~deb8u1 (source all) into oldstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 01 Feb 2019 11:20:52 -0500 Source: debian-security-support Binary: debian-security-support Architecture: source all Version: 2019.02.01~deb8u1 Distribution: jessie-security Urgency: medium Maintainer: Christoph Biedl Changed-By: Antoine Beaupré Description: debian-security-support - Debian security support coverage checker Changes: debian-security-support (2019.02.01~deb8u1) jessie-security; urgency=medium . * Team upload. * rebuild for jessie * revert incompatible debhelper changes Checksums-Sha1: 05833ad3d7c53f8543c7dde45df01621e2e8c9b0 1549 debian-security-support_2019.02.01~deb8u1.dsc dac38df471ecdec6f7f9c03e7bc80495d2bc06a4 28812 debian-security-support_2019.02.01~deb8u1.tar.xz 50a33fb81e3a64f565e37f2fbc4560278c739860 28142 debian-security-support_2019.02.01~deb8u1_all.deb Checksums-Sha256: 152a6cdf14185ec82fc926e98a7e85aa05981bf702b48706a647292f85baccf4 1549 debian-security-support_2019.02.01~deb8u1.dsc bc5dad8cb0435cfe56f9f878053f9ec2c4c684c88c5108b020892eadecf6b859 28812 debian-security-support_2019.02.01~deb8u1.tar.xz 4ce7d0c944e78f7dab238b86c0352d46cc6b08fa24d15072f2fb98a06e8c8a52 28142 debian-security-support_2019.02.01~deb8u1_all.deb Files: 314b34f2bff72aa4d06e029ea3309674 1549 admin optional debian-security-support_2019.02.01~deb8u1.dsc 6d9a91d8d2f21a37407f8ac21c4bfdde 28812 admin optional debian-security-support_2019.02.01~deb8u1.tar.xz 364a4469239e2a6242b4d47e33b9110f 28142 admin optional debian-security-support_2019.02.01~deb8u1_all.deb -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEexZCBNCWcjsBljWrPqHd3bJh2XsFAlxUc1wACgkQPqHd3bJh 2XtnSggAiSp9WjLjEF9GA/xr/SQjGfhwfe5HUdpWBHWn9s2vYaoZql3GT0J3xrQP 0C8Ev82FqiqWgHt9/Q/9RHDG3WZDhCIC5DOD9j9hsu2qZrRvFcXjWPNNONmrZcMt fZY99HH2FwYJ4qSuBU7iaeJWlaIIG4pU+qKaNWa9T8XLKzyB/MMpYjxZ6W/K5ZUf op9Qcmv41EKZVaF1Xuq+Q6CNxNkY+ZHVrmqWBfWFHboXflsF7wfyvvdiaokAJEGx eKkVMxxRQnIP+wVbDkRqV6KyA00qv9Zr095jOtClk0FC8LqnIxc6lMwhucpFo1C8 NuMPRGbim1zyn+JwKjI5oV2iF2N7sA== =W0Cd -END PGP SIGNATURE-
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
[SECURITY] [DLA 1639-1] systemd security update
Package: systemd Version: 215-17+deb8u9 CVE ID : CVE-2018-16864 CVE-2018-16865 Debian Bug : 918841 918848 Multiple vulnerabilities were found in the journald component of systemd which can lead to a crash or code execution. CVE-2018-16864 An allocation of memory without limits, that could result in the stack clashing with another memory region, was discovered in systemd-journald when many entries are sent to the journal socket. A local attacker, or a remote one if systemd-journal-remote is used, may use this flaw to crash systemd-journald or execute code with journald privileges. CVE-2018-16865 An allocation of memory without limits, that could result in the stack clashing with another memory region, was discovered in systemd-journald when a program with long command line arguments calls syslog. A local attacker may use this flaw to crash systemd-journald or escalate his privileges. Versions through v240 are vulnerable. For Debian 8 "Jessie", these problems have been fixed in version 215-17+deb8u9. We recommend that you upgrade your systemd packages. Further information about Debian LTS security advisories, how to apply these updates to your system and frequently asked questions can be found at: https://wiki.debian.org/LTS signature.asc Description: PGP signature
Accepted systemd 215-17+deb8u9 (source amd64) into oldstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 22 Jan 2019 15:30:45 -0500 Source: systemd Binary: systemd systemd-sysv libpam-systemd libsystemd0 libsystemd-dev libsystemd-login0 libsystemd-login-dev libsystemd-daemon0 libsystemd-daemon-dev libsystemd-journal0 libsystemd-journal-dev libsystemd-id128-0 libsystemd-id128-dev udev libudev1 libudev-dev udev-udeb libudev1-udeb libgudev-1.0-0 gir1.2-gudev-1.0 libgudev-1.0-dev python3-systemd systemd-dbg Architecture: source amd64 Version: 215-17+deb8u9 Distribution: jessie-security Urgency: high Maintainer: Debian systemd Maintainers Changed-By: Antoine Beaupré Description: gir1.2-gudev-1.0 - libgudev-1.0 introspection data libgudev-1.0-0 - GObject-based wrapper library for libudev libgudev-1.0-dev - libgudev-1.0 development files libpam-systemd - system and service manager - PAM module libsystemd-daemon-dev - systemd utility library (transitional package) libsystemd-daemon0 - systemd utility library (deprecated) libsystemd-dev - systemd utility library - development files libsystemd-id128-0 - systemd 128 bit ID utility library (deprecated) libsystemd-id128-dev - systemd 128 bit ID utility library (transitional package) libsystemd-journal-dev - systemd journal utility library (transitional package) libsystemd-journal0 - systemd journal utility library (deprecated) libsystemd-login-dev - systemd login utility library (transitional package) libsystemd-login0 - systemd login utility library (deprecated) libsystemd0 - systemd utility library libudev-dev - libudev development files libudev1 - libudev shared library libudev1-udeb - libudev shared library (udeb) python3-systemd - Python 3 bindings for systemd systemd- system and service manager systemd-dbg - system and service manager (debug symbols) systemd-sysv - system and service manager - SysV links udev - /dev/ and hotplug management daemon udev-udeb - /dev/ and hotplug management daemon (udeb) Closes: 918841 918848 Changes: systemd (215-17+deb8u9) jessie-security; urgency=high . * Non-maintainer upload by the Security Team. * CVE-2018-16865: fix memory allocation overflow which could result in crash or code execution in journald's socket (Closes: #918848). * CVE-2018-16864: fix memory allocation overflow which could result in crash or code execution on journald's commandline (Closes: #918841) Checksums-Sha1: 18b8006859570d7804acea44adebbef5f561a08f 3804 systemd_215-17+deb8u9.dsc 04474dd61ad0a143be6684c12f59cbd88e744b18 244644 systemd_215-17+deb8u9.debian.tar.xz 952d4eb84771c9fe8c41e25494206cf1ce5053bf 2557310 systemd_215-17+deb8u9_amd64.deb 51982449538eb03c73bb1f32d55ed1de24a42043 37044 systemd-sysv_215-17+deb8u9_amd64.deb d1a87b8b724cbe83b051d4606d08ddf77c1875c4 127020 libpam-systemd_215-17+deb8u9_amd64.deb 85822ef0270e55396378dd883c775f33a0a140a0 89804 libsystemd0_215-17+deb8u9_amd64.deb a4748f345a2e720bb39b08db464fec580c155a2c 95956 libsystemd-dev_215-17+deb8u9_amd64.deb 37012b282cee1772d7cdc04668af95cbb722fe43 50150 libsystemd-login0_215-17+deb8u9_amd64.deb fabd9cbeb070c4b585a449c196aff1a50f4f84a2 32666 libsystemd-login-dev_215-17+deb8u9_amd64.deb b8ad90d6326bf9e941704ee35674a4ec6b19ace8 39280 libsystemd-daemon0_215-17+deb8u9_amd64.deb 61e6e048bcefeeb12bcda06a52ae59f709667c6e 32682 libsystemd-daemon-dev_215-17+deb8u9_amd64.deb 569ff903fcf6c0d89a9fdc551048c899d1acd9db 75518 libsystemd-journal0_215-17+deb8u9_amd64.deb 507dd5cc0ca1c6ac55501da4437f2a144a1c820a 32658 libsystemd-journal-dev_215-17+deb8u9_amd64.deb b7c5aee6bfbedf262c046cc804a0de643bbd4361 38216 libsystemd-id128-0_215-17+deb8u9_amd64.deb eb34b05d4e81a19ac8e4354a2c3ba9ab8014f528 32648 libsystemd-id128-dev_215-17+deb8u9_amd64.deb 0c69f730b728b1e7e3884df74ef68af27ddc19eb 877202 udev_215-17+deb8u9_amd64.deb 7e9a0b68d156af576db57a3fb383d358ced8c272 58144 libudev1_215-17+deb8u9_amd64.deb a836208d57d304f2bbb43bf603c48af30a8ae29e 23330 libudev-dev_215-17+deb8u9_amd64.deb a320355e57bdb60b1e8b7be3d9abc42c4a9bd698 195514 udev-udeb_215-17+deb8u9_amd64.udeb 2c32227b3fc32e34cd6d71a23e5512629da4f892 24712 libudev1-udeb_215-17+deb8u9_amd64.udeb 37114365096c75169bf2f20e552b23e8fe345495 42968 libgudev-1.0-0_215-17+deb8u9_amd64.deb 83d2745968169a3c0487aa4c209ae159d47eec1d 2824 gir1.2-gudev-1.0_215-17+deb8u9_amd64.deb 6ef026629b3b0b402ffeb92dde0fa7de70cc7543 24646 libgudev-1.0-dev_215-17+deb8u9_amd64.deb 0830df3c1d328ffd310e1ade0fdff73e26e50573 62438 python3-systemd_215-17+deb8u9_amd64.deb 9c36b9c85206f69fc56892bc0a8d490e1f2a8d54 16014788 systemd-dbg_215-17+deb8u9_amd64.deb Checksums-Sha256: 2edc973d09ee17f8877e5a7fab4dfde77ce6304abcebcf0ef9d587d30441b452 3804 systemd_215-17+deb8u9.dsc 6416de84422aae598a09f8652dcabe00c484e4ed7babcc8b595c8edf5fbd9fc1 244644 systemd_215-17+deb8u9.debian.tar.xz 2fd037a32bff67a8b9d1d028287ce0b2342a0684bdf5c2363093793da019b28b 2557310 systemd_215-17+deb8u9_amd64.deb
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]:
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
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 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
[SECURITY] [DLA 1580-1] systemd security update
Package: systemd Version: 215-17+deb8u8 CVE ID : CVE-2018-1049 CVE-2018-15686 CVE-2018-15688 Debian Bug : 912005 912008 systemd was found to suffer from multiple security vulnerabilities ranging from denial of service attacks to possible root privilege escalation. CVE-2018-1049 A race condition exists between .mount and .automount units such that automount requests from kernel may not be serviced by systemd resulting in kernel holding the mountpoint and any processes that try to use said mount will hang. A race condition like this may lead to denial of service, until mount points are unmounted. CVE-2018-15686 A vulnerability in unit_deserialize of systemd allows an attacker to supply arbitrary state across systemd re-execution via NotifyAccess. This can be used to improperly influence systemd execution and possibly lead to root privilege escalation. CVE-2018-15688 A buffer overflow vulnerability in the dhcp6 client of systemd allows a malicious dhcp6 server to overwrite heap memory in systemd-networkd, which is not enabled by default in Debian. For Debian 8 "Jessie", these problems have been fixed in version 215-17+deb8u8. We recommend that you upgrade your systemd packages. Further information about Debian LTS security advisories, how to apply these updates to your system and frequently asked questions can be found at: https://wiki.debian.org/LTS -- signature.asc Description: PGP signature
Accepted systemd 215-17+deb8u8 (source amd64) into oldstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 13 Nov 2018 14:44:47 -0500 Source: systemd Binary: systemd systemd-sysv libpam-systemd libsystemd0 libsystemd-dev libsystemd-login0 libsystemd-login-dev libsystemd-daemon0 libsystemd-daemon-dev libsystemd-journal0 libsystemd-journal-dev libsystemd-id128-0 libsystemd-id128-dev udev libudev1 libudev-dev udev-udeb libudev1-udeb libgudev-1.0-0 gir1.2-gudev-1.0 libgudev-1.0-dev python3-systemd systemd-dbg Architecture: source amd64 Version: 215-17+deb8u8 Distribution: jessie-security Urgency: medium Maintainer: Debian systemd Maintainers Changed-By: Antoine Beaupré Description: gir1.2-gudev-1.0 - libgudev-1.0 introspection data libgudev-1.0-0 - GObject-based wrapper library for libudev libgudev-1.0-dev - libgudev-1.0 development files libpam-systemd - system and service manager - PAM module libsystemd-daemon-dev - systemd utility library (transitional package) libsystemd-daemon0 - systemd utility library (deprecated) libsystemd-dev - systemd utility library - development files libsystemd-id128-0 - systemd 128 bit ID utility library (deprecated) libsystemd-id128-dev - systemd 128 bit ID utility library (transitional package) libsystemd-journal-dev - systemd journal utility library (transitional package) libsystemd-journal0 - systemd journal utility library (deprecated) libsystemd-login-dev - systemd login utility library (transitional package) libsystemd-login0 - systemd login utility library (deprecated) libsystemd0 - systemd utility library libudev-dev - libudev development files libudev1 - libudev shared library libudev1-udeb - libudev shared library (udeb) python3-systemd - Python 3 bindings for systemd systemd- system and service manager systemd-dbg - system and service manager (debug symbols) systemd-sysv - system and service manager - SysV links udev - /dev/ and hotplug management daemon udev-udeb - /dev/ and hotplug management daemon (udeb) Closes: 912005 912008 Changes: systemd (215-17+deb8u8) jessie-security; urgency=medium . * Non-maintainer upload by the LTS Security Team. * CVE-2018-1049: fix race condition between .mount and .automount unitspossibly leading to Denial of Service * CVE-2018-15686: fix improper serialization on upgrade which can influence systemd execution environment and lead to root privilege escalation (Closes: #912005) * CVE-2018-15688: fix buffer overflow vulnerability in the dhcp6 client of systemd, which allows a malicious dhcp6 server to overwrite heap memory in systemd-networkd, leading to denial of service or potential code execution. (Closes: #912008) Checksums-Sha1: 6807fc102608c572e58d5b6b8bdb052b410e18a8 3804 systemd_215-17+deb8u8.dsc 7a592f90c0c1ac05c43de45b8fde1f23b5268cb4 2888652 systemd_215.orig.tar.xz 6dd2a6846486a00a6ecf9a7ba858bcdee603d756 242872 systemd_215-17+deb8u8.debian.tar.xz 610a022e5461d5a13d6a1c5c70825e99db099889 2558452 systemd_215-17+deb8u8_amd64.deb 6c0ff1002027c4847a4c55c70e9031fa9b59fb5a 37090 systemd-sysv_215-17+deb8u8_amd64.deb 52792a998d6fc6e649dad1257686a76f0c2249e7 127028 libpam-systemd_215-17+deb8u8_amd64.deb 11553a4aa2d02e761e5b1d1126cdf632bf10a115 89846 libsystemd0_215-17+deb8u8_amd64.deb dcf14361c3f0c988e0ca61cd5ab69cc9828fda6f 96036 libsystemd-dev_215-17+deb8u8_amd64.deb 43c0628750fdafa2a3ff2714938a02a6ee094396 50214 libsystemd-login0_215-17+deb8u8_amd64.deb 2b43a37be4ab5867a5fb8f4622ab66239e26b0f0 32720 libsystemd-login-dev_215-17+deb8u8_amd64.deb dc007241992ba2ed12d89ade84d3c6c25ccfb218 39340 libsystemd-daemon0_215-17+deb8u8_amd64.deb 5405caad1551cf2ee8c9f617c85a346eea83961e 32748 libsystemd-daemon-dev_215-17+deb8u8_amd64.deb 35174e22d724f796092d5ac7eebbfb6a9e04d95e 75566 libsystemd-journal0_215-17+deb8u8_amd64.deb 0af7bb6ffc1b0a07e2a45d23eaf84dff5d834992 32716 libsystemd-journal-dev_215-17+deb8u8_amd64.deb 6861406dde466007a7763211a1880fb558bdb48a 38270 libsystemd-id128-0_215-17+deb8u8_amd64.deb 5832102fdfab1f9ee9c54643dfc7fff57d562fe6 32708 libsystemd-id128-dev_215-17+deb8u8_amd64.deb 3808af23373edafa6e60a08037e8ae791655b473 876190 udev_215-17+deb8u8_amd64.deb 149cd5cd4c01f02a644e10a5af65420dd441a763 58224 libudev1_215-17+deb8u8_amd64.deb 5d954da2a6877e301852b35cfa38ca01781d1c5e 23312 libudev-dev_215-17+deb8u8_amd64.deb 1501f8ce282754c08d929d3b806b803258a545ed 195536 udev-udeb_215-17+deb8u8_amd64.udeb bc24d56b07d9e4e9559c7b5cdd0608c6315d1323 24742 libudev1-udeb_215-17+deb8u8_amd64.udeb 393dd0a387cba56a3155e10d8d6ee7aae6ee0910 43020 libgudev-1.0-0_215-17+deb8u8_amd64.deb 23d457da2611739238c669b4a20a64cbc4738244 2834 gir1.2-gudev-1.0_215-17+deb8u8_amd64.deb dfd14d504abe28689723f6ffbb4b23b1341d0d3d 24644 libgudev-1.0-dev_215-17+deb8u8_amd64.deb 99bf38528d8aa28a7403530ae50c72c3d033f69a 62466 python3-systemd_215-17+deb8u8_amd64.deb 41d37cc9e24a5377531fd44918ad2e44e81d2094 16024628 systemd-dbg_215-17+deb8u8_amd64.deb Checksums-Sha256
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
[SECURITY] [DLA 1578-1] spamassassin security update
Package: spamassassin Version: 3.4.2-0+deb8u1 CVE ID : CVE-2016-1238 CVE-2017-15705 CVE-2018-11780 CVE-2018-11781 Debian Bug : 784023 865924 883775 889501 891041 908969 908970 908971 913571 Multiple vulnerabilities were found in Spamassassin, which could lead to Remote Code Execution and Denial of Service attacks under certain circumstances. CVE-2016-1238 Many Perl programs do not properly remove . (period) characters from the end of the includes directory array, which might allow local users to gain privileges via a Trojan horse module under the current working directory. CVE-2017-15705 A denial of service vulnerability was identified that exists in Apache SpamAssassin before 3.4.2. The vulnerability arises with certain unclosed tags in emails that cause markup to be handled incorrectly leading to scan timeouts. This can cause carefully crafted emails that might take more scan time than expected leading to a Denial of Service. CVE-2018-11780 A potential Remote Code Execution bug exists with the PDFInfo plugin in Apache SpamAssassin before 3.4.2. CVE-2018-11781 Apache SpamAssassin 3.4.2 fixes a local user code injection in the meta rule syntax. For Debian 8 "Jessie", these problems have been fixed in version 3.4.2-0+deb8u1. Upstream strongly advocates upgrading to the latest upstream version so we are following that recommendation and backported the version published as part of the 9.6 stretch release, which also fixes many critical bugs. We recommend that you upgrade your spamassassin packages. Further information about Debian LTS security advisories, how to apply these updates to your system and frequently asked questions can be found at: https://wiki.debian.org/LTS -- signature.asc Description: PGP signature
Accepted spamassassin 3.4.2-0+deb8u1 (source all amd64) into oldstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 30 Oct 2018 13:28:29 -0400 Source: spamassassin Binary: spamassassin spamc sa-compile Architecture: source all amd64 Version: 3.4.2-0+deb8u1 Distribution: jessie-security Urgency: high Maintainer: Noah Meyerhans Changed-By: Antoine Beaupré Description: sa-compile - Tools for compiling SpamAssassin rules into C spamassassin - Perl-based spam filter using text analysis spamc - Client for SpamAssassin spam filtering daemon Closes: 784023 865924 883775 889501 891041 908969 908970 908971 913571 Changes: spamassassin (3.4.2-0+deb8u1) jessie-security; urgency=high . * Non-maintainer upload by the LTS Security Team. * New upstream version to fix several security issues and critical bugs: - CVE-2017-15705: Denial of service issue in which certain unclosed tags in emails cause markup to be handled incorrectly leading to scan timeouts. (Closes: 908969) - CVE-2016-1238: Unsafe usage of "." in @INC in a configuration script. - CVE-2018-11780: potential Remote Code Execution bug with the PDFInfo plugin. (Closes: 908970) - CVE-2018-11781: local user code injection in the meta rule syntax. (Closes: 908971) - BayesStore: bayes_expire table grows, remove_running_expire_tok not called (Closes: 883775) - Fix use of uninitialized variable warning in PDFInfo.pm (Closes: 865924) - Fix "failed to parse plugin" error in Mail::SpamAssassin::Plugin::URILocalBL (Closes: 891041) - SSLv3 support removed from spamc * Don't recursively chown /var/lib/spamassassin during postinst. (Closes: 889501) * Update SysV init script to cope with upstream's change to $0. * Run test suite during build (Closes: #784023). * Refresh patches * Removed patches merged upstream: - 30_edit_README - 35_bug752542-libnet-dns-perl.patch - 97_bug720499-pod-5.18 - bug_771408_perl_version - bug_774768_disable_ahbl * Added patch to silence extra debugging messages (Closes: #913571) Checksums-Sha1: 3454a58e1b7fb91284a706949219bb01142e446d 2126 spamassassin_3.4.2-0+deb8u1.dsc a7c72a47e9aa88276aeefc926a159c27dc4a74ab 234232 spamassassin_3.4.2.orig-pkgrules.tar.xz f295571631e4163225ee3eab04d5c0cce3a69fbc 1873396 spamassassin_3.4.2.orig.tar.xz 3618a83860fb605b35983ca7b997871652134791 36876 spamassassin_3.4.2-0+deb8u1.debian.tar.xz 679a3814a3993d7902778d30389dba61216409b3 1176290 spamassassin_3.4.2-0+deb8u1_all.deb af1ee6858931ad81f389002622e2f2976af6e5fe 46968 sa-compile_3.4.2-0+deb8u1_all.deb f3c14a2296d26c70cdd8aba3f21e5ff162a82fed 81194 spamc_3.4.2-0+deb8u1_amd64.deb Checksums-Sha256: 4d3fa6333bbcb6a62ebe83c8187c0489da0df5de433213cb7cc7ac16fb53fc65 2126 spamassassin_3.4.2-0+deb8u1.dsc 3f3349bb45ac63a7b85a7562a365a9805c4afce91aa11718f0dacfe034890066 234232 spamassassin_3.4.2.orig-pkgrules.tar.xz aae73f835e1201713458fbe012f686eae395f7672c4729e62c91a92b3ced50df 1873396 spamassassin_3.4.2.orig.tar.xz a44de59dce688c9e02a081797229404bb2ad296214365ce0d979ce9e25d2c363 36876 spamassassin_3.4.2-0+deb8u1.debian.tar.xz 89e3063d4733665835fcf82104e612231bb242cffbeb44d8ac778f743e56bb10 1176290 spamassassin_3.4.2-0+deb8u1_all.deb 8a2aa523c733d48657b81d6dba1fe62d59526c61d4a6d0c00f84d6570e673a66 46968 sa-compile_3.4.2-0+deb8u1_all.deb 0f06178a02f6b123c8675b1f6572520bd0ff6e3b84416e74b6f65725ae0d0505 81194 spamc_3.4.2-0+deb8u1_amd64.deb Files: a245f95524a82c86906e8582e3f6b176 2126 mail optional spamassassin_3.4.2-0+deb8u1.dsc d1616326f1d3a442aff01347e615cabd 234232 mail optional spamassassin_3.4.2.orig-pkgrules.tar.xz 0f6d6733613ec670b13d37ce6f6244f8 1873396 mail optional spamassassin_3.4.2.orig.tar.xz 1065a02ec5c934835398f377c01a3216 36876 mail optional spamassassin_3.4.2-0+deb8u1.debian.tar.xz 9c47273d94caa3cbf8e8835562f7f089 1176290 mail optional spamassassin_3.4.2-0+deb8u1_all.deb ca299ea1fba3396d1eae3061bf6dd52f 46968 mail optional sa-compile_3.4.2-0+deb8u1_all.deb 46d2e6e39cf11215eb07dd026a870174 81194 mail optional spamc_3.4.2-0+deb8u1_amd64.deb -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEexZCBNCWcjsBljWrPqHd3bJh2XsFAlvrGtsACgkQPqHd3bJh 2Xto2Af/TXe0JQP+l1bhV9ooDC0gkTX7Mmt6OXkWXdjuAreBcJcFHf41wg1a0r8L m6Ar3noRfgCgsfsxl2zX1pDFHPBWuIgm2ojvHkDGxwzXklmEf0u0kMJf37obAONj HY0v9qdxDdgI67lsH8g1qsaqahfz77YK9uoDAvoKHLV+mzjZAkarBSLXSKgvbvnk ArbParEvl0/L0mjSVrA258X0tSnSGKK/DKdrl327L7nDYEUsg9GEH/pgVcmMAZMt j3dT+ez4+3A04YjaNlqPASzuJraKC4WeVoFZE8ai0GYFN6PuZNr3zd+2uo1PbesB XTBMng9+wxE8W3bbEy/XgtmEDT0IWA== =3PR9 -END PGP SIGNATURE-
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
[SECURITY] [DLA 1561-1] phpldapadmin security update
Package: phpldapadmin Version: 1.2.2-5.2+deb8u1 CVE ID : CVE-2017-11107 Debian Bug : 867719 It was discovered that there was a cross-site scripting (XSS) vulnerability in phpldapadmin, a web-based interface for administering LDAP servers. For Debian 8 "Jessie", this problem has been fixed in version 1.2.2-5.2+deb8u1. Note: the package changelog mistakenly refers to the non-existent CVE-2016-11107 identifier. The proper identifier to refer to this issue is CVE-2017-11107. We recommend that you upgrade your phpldapadmin packages. Further information about Debian LTS security advisories, how to apply these updates to your system and frequently asked questions can be found at: https://wiki.debian.org/LTS -- signature.asc Description: PGP signature
Accepted phpldapadmin 1.2.2-5.2+deb8u1 (source all) into oldstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 31 Oct 2018 13:30:20 -0400 Source: phpldapadmin Binary: phpldapadmin Architecture: source all Version: 1.2.2-5.2+deb8u1 Distribution: jessie-security Urgency: medium Maintainer: Fabio Tranchitella Changed-By: Antoine Beaupré Description: phpldapadmin - web based interface for administering LDAP servers Closes: 867719 Changes: phpldapadmin (1.2.2-5.2+deb8u1) jessie-security; urgency=medium . * Non-maintainer upload by the LTS Security Team. * CVE-2016-11107: Fix a cross-site scripting (XSS) vulnerabily in entry_chooser.php. (Closes: #867719) Checksums-Sha1: 4ee0b66b568f3f26bc129067e91fd639c521868b 1478 phpldapadmin_1.2.2-5.2+deb8u1.dsc be14ffdfbc257dafcefc204b20cf44b7729c77d4 30520 phpldapadmin_1.2.2-5.2+deb8u1.debian.tar.xz 40158ea2bd607ed58a60ddf31272757d5815ded6 753502 phpldapadmin_1.2.2-5.2+deb8u1_all.deb Checksums-Sha256: 92fee10985cdbc53323108b0d8af4ca0098d46bc028ef81818dd08aebfeae9e0 1478 phpldapadmin_1.2.2-5.2+deb8u1.dsc fbfab0a5ffe2d8b265ce815b4c3aa2b30e36c8b2ec83e6e30391c722562d58e7 30520 phpldapadmin_1.2.2-5.2+deb8u1.debian.tar.xz 353ad4ad4031f009391bbb11ed13489de1fab0b839c4da3def815b20b900a5d3 753502 phpldapadmin_1.2.2-5.2+deb8u1_all.deb Files: 854c741b5042ad73064b9d8133653206 1478 admin extra phpldapadmin_1.2.2-5.2+deb8u1.dsc 10e28c7e6555d9c6de6769b3c944845c 30520 admin extra phpldapadmin_1.2.2-5.2+deb8u1.debian.tar.xz a229f85e7526b19ee97c3f23a5f6760f 753502 admin extra phpldapadmin_1.2.2-5.2+deb8u1_all.deb -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEexZCBNCWcjsBljWrPqHd3bJh2XsFAlvZ5yEACgkQPqHd3bJh 2XvLDAf+JVr5TWXDN06cckQhMUaKziMp85ftUl1pz28ojb5jKbZz8MQel/TimoI6 6cHBxR340VrMmqEVWWbJopuv99OvfgrREgbC4q+oGo/ahL/baRKjo9Xx0UrHV/Yt c+dC5INryERSyxT/jxY/MSAMb7L/QFq7hqHyMw1qVM+oWgyce3ahlAKYkzCdfc77 tn/AuPpq8yDH7f3WzkfAEr6WhqLEskS4TCgQ98rGKW1nHz4Xzx+4UTcycDOvWIV0 sV//8v6GLg0hWA2ZAMPQm0bnHl130FLpbRLUopgVWohMMxAEjj2Ex6wQs/xptVQo 7CPoAs1H13/WFGpGRT0ZjmgxdzA50g== =nVuR -END PGP SIGNATURE-
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
[SECURITY] [DLA 1560-1] gnutls28 security update
Package: gnutls28 Version: 3.3.30-0+deb8u1 CVE ID : CVE-2018-10844 CVE-2018-10845 CVE-2018-10846 A set of vulnerabilities was discovered in GnuTLS which allowed attackers to do plain text recovery on TLS connections with certain cipher types. CVE-2018-10844 It was found that the GnuTLS implementation of HMAC-SHA-256 was vulnerable to a Lucky thirteen style attack. Remote attackers could use this flaw to conduct distinguishing attacks and plaintext-recovery attacks via statistical analysis of timing data using crafted packets. CVE-2018-10845 It was found that the GnuTLS implementation of HMAC-SHA-384 was vulnerable to a Lucky thirteen style attack. Remote attackers could use this flaw to conduct distinguishing attacks and plain text recovery attacks via statistical analysis of timing data using crafted packets. CVE-2018-10846 A cache-based side channel in GnuTLS implementation that leads to plain text recovery in cross-VM attack setting was found. An attacker could use a combination of "Just in Time" Prime+probe attack in combination with Lucky-13 attack to recover plain text using crafted packets. For Debian 8 "Jessie", these problems have been fixed in version 3.3.30-0+deb8u1. It was found to be more practical to update to the latest upstream version of the 3.3.x branch since upstream's fixes were rather invasive and required cipher list changes anyways. This will facilitate future LTS updates as well. This change therefore also includes the following major policy changes, as documented in the NEWS file: * ARCFOUR (RC4) and SSL 3.0 are no longer included in the default priorities list. Those have to be explicitly enabled, e.g., with a string like "NORMAL:+ARCFOUR-128" or "NORMAL:+VERS-SSL3.0", respectively. * The ciphers utilizing HMAC-SHA384 and SHA256 have been removed from the default priority strings. They are not necessary for compatibility or other purpose and provide no advantage over their SHA1 counter-parts, as they all depend on the legacy TLS CBC block mode. * Follow closely RFC5280 recommendations and use UTCTime for dates prior to 2050. * Require strict DER encoding for certificates, OCSP requests, private keys, CRLs and certificate requests, in order to reduce issues due to the complexity of BER rules. * Refuse to import v1 or v2 certificates that contain extensions. API and ABI compatibility is retained, however, although new symbols have been added. Many bugfixes are also included in the upload. See the provided upstream changelog for more details. We recommend that you upgrade your gnutls28 packages and do not expect significant breakage. Further information about Debian LTS security advisories, how to apply these updates to your system and frequently asked questions can be found at: https://wiki.debian.org/LTS signature.asc Description: PGP signature
Accepted gnutls28 3.3.30-0+deb8u1 (source amd64 all) into oldstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 30 Oct 2018 10:26:33 -0400 Source: gnutls28 Binary: libgnutls28-dev libgnutls-deb0-28 libgnutls28-dbg gnutls-bin gnutls-doc guile-gnutls libgnutlsxx28 libgnutls-openssl27 Architecture: source amd64 all Version: 3.3.30-0+deb8u1 Distribution: jessie-security Urgency: medium Maintainer: Debian GnuTLS Maintainers Changed-By: Antoine Beaupré Description: gnutls-bin - GNU TLS library - commandline utilities gnutls-doc - GNU TLS library - documentation and examples guile-gnutls - GNU TLS library - GNU Guile bindings libgnutls-deb0-28 - GNU TLS library - main runtime library libgnutls-openssl27 - GNU TLS library - OpenSSL wrapper libgnutls28-dbg - GNU TLS library - debugger symbols libgnutls28-dev - GNU TLS library - development files libgnutlsxx28 - GNU TLS library - C++ runtime library Changes: gnutls28 (3.3.30-0+deb8u1) jessie-security; urgency=medium . * Non-maintainer upload by the LTS Security Team. * Backport 3.3.30 from upstream to address CVE-2018-10844, CVE-2018-10845 and CVE-2018-10846. * Add net-tools dependency for test suite which expects the netstat command. * Removed patches already present upstream: * 35_recheck_urandom_fd.diff * 36_less_refresh-rnd-state.diff * 37_X9.63_sanity_check.diff * 38_testforsanitycheck.diff * 39_check-whether-the-two-signatur.patch * 40_no_more_ssl3.diff * 45_eliminated-double-free.diff * 46_Better-fix-for-the-double-free.diff * 47_GNUTLS-SA-2015-3.patch * 50_Handle-zero-length-plaintext-for-VIA-PadLock-functio.patch * 51_0001__gnutls_session_sign_algo_enabled-do-not-consider-an.patch * 51_0002_before-falling-back-to-SHA1-as-signature-algorithm-i.patch * 51_0003_tests-added-reproducer-for-the-MD5-acceptance-issue.patch * 52_CVE-2016-7444_ocsp-corrected-the-comparison-of-the-serial-size-in-.patch * 53_nettle-use-rsa_-_key_prepare-on-key-import.patch * 55_00_pkcs12-fixed-the-calculation-of-p_size.patch * 55_01_gnutls_x509_ext_import_proxy-fix-issue-reading-the-p.patch * 55_02_auth-rsa-eliminated-memory-leak-on-pkcs-1-formatting.patch * 55_03_opencdk-Fixes-to-prevent-undefined-behavior-found-wi.patch * 55_04_Do-not-infinite-loop-if-an-EOF-occurs-while-skipping.patch * 55_05_Attempt-to-fix-a-leak-in-OpenPGP-cert-parsing.patch * 55_06_Corrected-a-leak-in-OpenPGP-sub-packet-parsing.patch * 55_07_opencdk-read_attribute-added-more-precise-checks-whe.patch * 55_08_opencdk-cdk_pk_get_keyid-fix-stack-overflow.patch * 55_09_opencdk-added-error-checking-in-the-stream-reading-f.patch * 55_10_opencdk-improved-error-code-checking-in-the-stream-r.patch * 55_11_opencdk-read-packet.c-corrected-typo-in-type-cast.patch * 55_12_gnutls_pkcs11_obj_list_import_url2-Always-return-an-.patch * 55_13_cdk_pkt_read-enforce-packet-limits.patch * 55_15_opencdk-do-not-parse-any-secret-keys-in-packet-when-.patch * 55_16_Enforce-the-max-packet-length-for-OpenPGP-subpackets.patch * 56_CVE-2017-7507_1-ext-status_request-ensure-response-IDs-are-pro.patch * 56_CVE-2017-7507_2-ext-status_request-Removed-the-parsing-of-resp.patch * 56_CVE-2017-7507_3-gnutls_ocsp_status_request_enable_client-docum.patch * 57_urandom-use-st_ino-and-st_rdev-to-determine-device-u.patch Checksums-Sha1: 7d7bc6a7d1ded21878fa42c2966638b87455fd51 2628 gnutls28_3.3.30-0+deb8u1.dsc 05d7e38e1b386be9683a23f873b7e049d49db332 6392748 gnutls28_3.3.30.orig.tar.xz 5e38dfe5ea73d6339251599d1f7983c724976bca 46352 gnutls28_3.3.30-0+deb8u1.debian.tar.xz 16d8f1e9850b85ac669e77e4ff18aa8aa0523e22 686078 libgnutls28-dev_3.3.30-0+deb8u1_amd64.deb 9d55faa617eea6e2911e10dac247edbd8089c032 749304 libgnutls-deb0-28_3.3.30-0+deb8u1_amd64.deb 5a8d1dfc88e7c3313f45543b25a75e2ce893329c 2379100 libgnutls28-dbg_3.3.30-0+deb8u1_amd64.deb de17b17a6b1af46e5adf142af687405900d2e077 340728 gnutls-bin_3.3.30-0+deb8u1_amd64.deb 43b935c8a92c72529d625de5e7ddb4a1716f9e4f 3686044 gnutls-doc_3.3.30-0+deb8u1_all.deb 17cae70e045184faaf7c12d0c3f100357d4b355d 213076 guile-gnutls_3.3.30-0+deb8u1_amd64.deb 127e8b4f9f8932bb158dd655c116212015576fbc 14668 libgnutlsxx28_3.3.30-0+deb8u1_amd64.deb d7a59e9c023fcee34d88dd7936fe77fd692d174d 180440 libgnutls-openssl27_3.3.30-0+deb8u1_amd64.deb Checksums-Sha256: 01be8c173d3ffbe984b5dddb3ada3f6e984e1219daf9d9af14c0512b965a3dbb 2628 gnutls28_3.3.30-0+deb8u1.dsc 41d70107ead3de2f12390909a05eefc9a88def6cd1f0d90ea82a7dac8b8effee 6392748 gnutls28_3.3.30.orig.tar.xz f3055451c76ba5c805f558b676bc5b83fbbc5cce9332d2fc0bece2c180165d6f 46352 gnutls28_3.3.30-0+deb8u1.debian.tar.xz b04cb507f549dcaa3eb2c4ece627134ff093fb369b1b6f635f53b207cdf7f55c 686078 libgnutls28-dev_3.3.30-0+deb8u1_amd64.deb 2f6c44f0ba6a4b4261c58065843b4997c796b6346f2784d4fe8f949fb136ea1c 749304 libgnutls-deb0-28_3.3.30-0+deb8u1_amd64.deb
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: 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: 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 issues affect all versions of Xen. I know a
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: 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: 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
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
