Re: heads up: DLA should now be published on the website

2019-02-21 Thread Antoine Beaupré
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

2019-02-18 Thread Antoine Beaupré
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

2019-02-18 Thread Antoine Beaupré
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"

2019-02-18 Thread Antoine Beaupré
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"

2019-02-14 Thread Antoine Beaupré
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

2019-02-12 Thread Antoine Beaupré
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

2019-02-11 Thread Antoine Beaupré
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

2019-02-11 Thread Antoine Beaupré
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

2019-02-11 Thread Antoine Beaupré
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

2019-02-11 Thread Antoine Beaupré
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

2019-02-08 Thread Antoine Beaupré
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

2019-02-08 Thread Antoine Beaupré
-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

[SECURITY] [DLA 1668-1] libarchive security update

2019-02-07 Thread Antoine Beaupré
Package: libarchive
Version: 3.1.2-11+deb8u7
CVE ID : CVE-2019-119 CVE-2019-120

Fuzzing found two further file-format specific issues in libarchive, a
read-only segfault in 7z, and an infinite loop in ISO9660.

CVE-2019-119

Out-of-bounds Read vulnerability in 7zip decompression, that can
result in a crash (denial of service, CWE-125)
   
CVE-2019-120

Vulnerability in ISO9660 parser that can result in DoS by infinite
loop (CWE-835)

For Debian 8 "Jessie", these problems have been fixed in version
3.1.2-11+deb8u7.

We recommend that you upgrade your libarchive 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 libarchive 3.1.2-11+deb8u7 (source amd64) into oldstable

2019-02-07 Thread Antoine Beaupré
-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?

2019-02-07 Thread Antoine Beaupré
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?

2019-02-07 Thread Antoine Beaupré
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

2019-02-07 Thread Antoine Beaupré
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

2019-02-07 Thread Antoine Beaupré
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

2019-02-07 Thread Antoine Beaupré
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?

2019-02-07 Thread Antoine Beaupré
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

2019-02-06 Thread Antoine Beaupré
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

2019-02-06 Thread Antoine Beaupré
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

2019-02-06 Thread Antoine Beaupré
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

2019-02-06 Thread Antoine Beaupré
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

2019-02-06 Thread Antoine Beaupré
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

2019-02-06 Thread Antoine Beaupré
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?

2019-02-05 Thread Antoine Beaupré
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

2019-02-04 Thread Antoine Beaupré
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

2019-02-03 Thread Antoine Beaupré
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

2019-02-01 Thread Antoine Beaupré
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

2019-02-01 Thread Antoine Beaupré
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

2019-02-01 Thread Antoine Beaupré
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

2019-02-01 Thread Antoine Beaupré
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

2019-02-01 Thread Antoine Beaupré
-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

2019-01-29 Thread Antoine Beaupré
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

2019-01-22 Thread Antoine Beaupré
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

2019-01-22 Thread Antoine Beaupré
-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

2019-01-22 Thread Antoine Beaupré
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)

2018-12-27 Thread Antoine Beaupré
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

2018-12-21 Thread Antoine Beaupré
[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

2018-12-21 Thread Antoine Beaupré
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

2018-12-21 Thread Antoine Beaupré
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

2018-12-19 Thread Antoine Beaupré
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

2018-12-19 Thread Antoine Beaupré
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

2018-12-19 Thread Antoine Beaupré
On 2018-12-19 21:22:21, Emilio Pozuelo Monfort wrote:
> Hi Antoine,
>
> On 19/12/2018 18:25, Antoine Beaupré wrote:
>> On 2018-12-19 17:03:26, Holger Levsen wrote:
>>> On Wed, Dec 19, 2018 at 11:40:07AM -0500, Antoine Beaupré wrote:
>>> [...]
>>> I've now also re-read this thread (for the 2nd time today..) and first
>>> I'd like to notice that all the concerns were only brought up in the
>>> last week, so it was definitly right from you to work on this for those
>>> months. Second, it now reads to me as if Emilio changed his mind after
>>> expressing concerns on Dec 14th, he indeed replied much more favorably
>>> on the 18th.
>> 
>> Thanks for your message, I'm relieved and happy to get support from
>> you. :)
>
> I'm sorry if my comments caused your frustration. I think you have done an
> amazing job getting all this work done. I just think we need to try and 
> balance
> the goal of supporting all packages that we can, versus the risk or causing
> regressions in important stuff.

You're right. Sorry I might have overreacted - I am going through some
intense family issues right now and I might be a little jittery. :)

>>> I mostly worried that you didnt test all dependent packages and that we
>>> essentially might break those when trying to support a package no
>>> customer has expressed need for. But then I also suppose such breakage
>>> could be fixed...
>> 
>> So I was mostly concerned about libgcrypt dependencies, and in
>> particular cryptsetup, and smoke tests seems to go through okay
>> there, for what that's worth...
>
> cryptsetup is definitely one of the main rdeps.  Also libgcrypt20 is used by
> systemd, ntfs-3g. There's also libssh, which is used by e.g. qemu, php-ssh2,
> libcurl...
>
> That doesn't mean we can't upgrade it. It just means it's an important package
> and the risk is higher due to its wide use and because of the extensive 
> changes.
> Just need to be extra careful.

Right.

>>> and now we are back to square one :/
>> 
>> Not really. We're actually at square N-1, we just need to do that one
>> final jump to get in the "let's actually support that newer version"
>> game. :p
>> 
>> Should we pursue this? Are there any other packages that should be
>> tested?
>> 
>> Would love other people's opinion as well...
>
> Maybe some of the other rdeps. libssh test suite (if it has one), systemd...
> However in the end it will come down to whether you feel confident to push 
> that
> out or think it's better to stay put.
>
> Whatever you decide, I'll do my best to help in any way I can.

That's great! :) Unfortunately I'm running out of time this month - I
have a measly 2-3h left this month and holidays are coming up so I don't
know if I'll be able to complete this before the new year.

A.
-- 
Celui qui ne connaît pas l'histoire est condamné à la revivre.
- Karl Marx



Re: proposed removal of Enigmail from jessie/LTS

2018-12-19 Thread Antoine Beaupré
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

2018-12-19 Thread Antoine Beaupré
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

2018-12-19 Thread Antoine Beaupré
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

2018-12-19 Thread Antoine Beaupré
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

2018-12-19 Thread Antoine Beaupré
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

2018-12-14 Thread Antoine Beaupré
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

2018-12-13 Thread Antoine Beaupré
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)

2018-12-11 Thread Antoine Beaupré
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

2018-12-11 Thread Antoine Beaupré
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)

2018-12-11 Thread Antoine Beaupré
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

2018-12-03 Thread Antoine Beaupré
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

2018-11-29 Thread Antoine Beaupré
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)

2018-11-26 Thread Antoine Beaupré
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)

2018-11-26 Thread Antoine Beaupré
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)

2018-11-23 Thread Antoine Beaupré
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

2018-11-22 Thread Antoine Beaupré
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)

2018-11-22 Thread Antoine Beaupré
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)

2018-11-22 Thread Antoine Beaupré
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

2018-11-22 Thread Antoine Beaupré
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

2018-11-20 Thread Antoine Beaupré
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

2018-11-19 Thread Antoine Beaupré
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

2018-11-19 Thread Antoine Beaupré
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

2018-11-19 Thread Antoine Beaupré
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

2018-11-19 Thread Antoine Beaupré
-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

2018-11-19 Thread Antoine Beaupré
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

2018-11-19 Thread Antoine Beaupré
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

2018-11-19 Thread Antoine Beaupré
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

2018-11-16 Thread Antoine Beaupré
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

2018-11-13 Thread Antoine Beaupré
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

2018-11-13 Thread Antoine Beaupré
-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

2018-11-13 Thread Antoine Beaupré
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

2018-11-13 Thread Antoine Beaupré
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

2018-11-12 Thread Antoine Beaupré
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

2018-11-11 Thread Antoine Beaupré
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

2018-11-11 Thread Antoine Beaupré
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

2018-11-09 Thread Antoine Beaupré
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

2018-11-06 Thread Antoine Beaupré
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

2018-10-31 Thread Antoine Beaupré
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

2018-10-31 Thread Antoine Beaupré
-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

2018-10-30 Thread Antoine Beaupré
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

2018-10-30 Thread Antoine Beaupré
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

2018-10-30 Thread Antoine Beaupré
-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

2018-10-30 Thread Antoine Beaupré
Hi,

In the last month, I have work with dkg (in CC) to see how to
(ultimately) deal with the end of life of Firefox and Thunderbird ESR as
we know them in jessie. He has been hard at work updating GnuPG in
stable (#910398) so that Enigmail works with that older version of GnuPG
without introducing new security issues. Next step is an update of
Enigmail in stable (in #912194) so that it works with the latest
Thunderbird 60 upload approved by the security team in mid-september.

Because Emilio (also in CC) had claimed the Thunderbird and Firefox
package, I figured I would see what would be required to deal with the
consequences of such an update in jessie. It seemed obvious an update to
at least Enigmail would be required, so I started to drill down into
that. I provided code reviews, rubber-ducking and support to dkg in the
Enigmail and GnuPG updates, mostly in private, but those are now
trickling down in stable updates.

Now, unfortunately, I am back here asking you what we should do about
those packages again. About a month ago, I offered 5 different options:

 1. pretend Enigmail works without changing GnuPG, possibly introducing
security issues

 2. ship a backport of GnuPG and Enigmail through jessie-sloppy-backports

 3. package OpenPGP.js and backport all the way down to jessie

 4. remove Enigmail from jessie

 5. backport the required GnuPG patchset from stretch to jessie

I believe we have now actively researched most of those issues in one
way or the other:

 1. I verified that Enigmail does indeed has security issues with the
current versions of GnuPG, particularly in the Autocrypt mechanism.

 2. was never seriously considered

 3. I investigated the OpenPGP.js dependency tree and determined it was
an impassable forest

 4. hasn't been seriously considered yet, as far as I can tell

 5. I have helped dkg backport the patches from GnuPG 2.2 to 2.1 for
stretch

Now I come back to you again for advice. Which path should we take? So
far I'm sticking to option #5 above, but I would welcome other opinions.

I would suggest we wait for Enigmail and GnuPG to trickle down to
stretch and see if any critical issues come out. There are specifically
concerns that the backported GnuPG changes might break unrelated
software that depend on the brittle dialect GnuPG imposes on its
consumers, which *does* change in the backport. I am aware of at least
one program (Monkeysphere) which could FTBFS because of a too brittle,
build-time, test suite. dkg and I are maintainers on that package and
will be able to handle the followup.

That should eventually settle Enigmail/GnuPG: either we backport GnuPG
patches, or we deem the GnuPG patchset is too invasive to backport to
jessie and we remove Enigmail from jessie. The result will be that users
will run an outdated version (if they don't notice the package's removed
or the announcement) or will run an up to date but possibly insecure
version (if they install the Addons version from Mozilla which downloads
an arbitrary binary from the network, see #891882). So I think there's a
strong incentive in backporting the changes, but we should wait and see
what breaks in stable before venturing any further into this dark alley.

Which brings us to Thunderbird (and Firefox) themselves. The last I
heard of this is that LLVM was NEW in jessie. I wrote Emilio to see if
he needed help on that last week, but haven't got a response. Hopefully
all that work will come to fruitition synchronously in a grand fanfare
of uploads all working out perfectly in the end. :)

Voilà. I felt I had been working in the dark on this for a part of
October and figured it would be useful to post a refresher on my
work. Let me know if that's useful / too long / or have any more
questions.

A.

-- 
Si les triangles avaient un Dieu, ils lui donneraient trois côtés.
- Montesquieu, Lettres persanes



Re: Wheezy update of spamassassin?

2018-10-29 Thread Antoine Beaupré
On 2018-10-29 09:50:41, Moritz Muehlenhoff wrote:
> On Sun, Oct 28, 2018 at 10:19:34PM -0700, Noah Meyerhans wrote:
>> On Mon, Oct 22, 2018 at 11:23:50AM -0400, Antoine Beaupré wrote:
>> > Ping! Any update here? Do you want us to help with the jessie or stretch
>> > update?
>> 
>> I'll be posting a message about the stretch update to debian-release
>> shortly. If you want to work on further backporting its update to
>> jessie, that is fine with me. The packaging changes for stretch are at
>> https://salsa.debian.org/debian/spamassassin/tree/3.4.2-stretch
>
> Make sure to only release anything after stretch 9.6 has been released, 
> though.
> Otherwise having a higher version in oldstable will cause update problems to
> stretch.

In any case I'll post a lower version number, if/when I do. Thanks!

A.

-- 
Premature optimization is the root of all evil
- Donald Knuth



Re: backported gnutls28 3.3.30 packages availabled for jessie LTS

2018-10-26 Thread Antoine Beaupré
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?

2018-10-26 Thread Antoine Beaupré
On 2018-10-26 13:02:57, Thadeu Lima de Souza Cascardo wrote:
>> > 5) Is that not true anymore with Extended LTS and CIP?
>> 
>> Sorry, what is not true? #4? If so, I think people should *still*
>> install the latest supported Debian release (stable or stretch right
>> now) and not LTS or ELTS, when deploying new systems.
>
> Yeah, not true that Stretch would have a latest term support compared to
> any earlier release. So, if one needs something that lasts 12 years,
> should one be picking up Stretch, Jessie or Wheezy?

"12 years" ... it depends when you start counting. Do you count from the
release date of the software? Or "now"? Because if you want 12 years
support, jessie, even less so wheezy is not going to help you.

>From that perspective, you might stand a better chance of installing
*unstable* or *buster* right now if you want the longer support schedule
from *right now* because then you'll get the buster release cycle (three
years, starting from late 2019 if not 2020), then LTS (two years) and
maybe even an extra ELTS (a year or more) slapped on top, which will
bring you somewhere somewhere close to 2027. That's 9 years from now, a
far cry from your 12 years objective, but it's pretty much the best shot
we have.

12-year support cycle is the crazy stuff they do at Solaris, or at least
did. Since Oracle bought it, they bumped that up to *twenty* years:

https://en.wikipedia.org/wiki/Solaris_(operating_system)#Version_history

We're still far away from that goal. And keep in mind the Solaris that
is supported there is a very limited operating system when compared with
the scope of packages supported in Debian...

A.

-- 
La seule excuse de Dieu, c'est qu'il n'existe pas.
- Stendhal



Re: Confusing our users - who is supporting LTS?

2018-10-26 Thread Antoine Beaupré
On 2018-10-26 10:26:09, Thadeu Lima de Souza Cascardo wrote:
> On Wed, Oct 24, 2018 at 09:30:46AM +0800, Paul Wise wrote:
>> On Wed, Oct 24, 2018 at 4:15 AM Sean Whitton wrote:
>> >
>> > On Tue 23 Oct 2018 at 05:06PM +0200, Markus Koschany wrote:
>> > >
>> > > In short: Make it very clear if you want to provide long-term support
>> > > for your project. Talk to the LTS team in case you need help. Nobody is
>> > > forced to do anything.
>> >
>> > This is a good idea, but ISTM the assumption should be that the
>> > subproject does not participate unless it explicitly says that it does.
>> 
>> This thread started because users have the opposite assumption. So I
>> think it would be better to be explicit about support teams and
>> timelines.
>> 
>> -- 
>> bye,
>> pabs
>> 
>> https://wiki.debian.org/PaulWise
>> 
>
> I am guessing one of the other (incorrect) assumption users might make
> is that the "LTS version" is preferred over other versions. That's how
> LTS works for Linux and Ubuntu, for example. So, a user would rather
> install Ubuntu 18.04 that is supported for 5 years than Ubuntu 18.10,
> that is supported for 9 months. The same happens with Linux 4.14 versus
> Linux 4.18.

I agree that is a concern...

> I am not sure it's clear to users that all Debian stable versions would
> have Long Term Support, because the releases are not *labeled* as LTS. I
> know the wiki says:
>
> "Debian Long Term Support (LTS) is a project to extend the lifetime of
> *all* Debian stable releases to (at least) 5 years." (emphasis mine)
>
> But I believe the table right below that would still confuse some users
> that would understand that Jessie is supported by LTS, while Stretch is
> not, even though there is a schedule column there.

... but, well, that is pretty clear isn't it? "All" releases are
supported, and "stretch" is explicitely mentioned in the table. I think
we've done our part.

> Using the LTS term in a slightly different way than the "industry
> standard" now means we need to spend a little more effort on users
> education.

I'm not sure we're using it that differently. But it's true normal
stable releases don't immediately get marked as LTS. There are good
reasons for that, and those would be very hard to work around. To get
more explicit, we can answer your questions one by one:

> Should we:
>
> 1) Start calling the stable releases as LTS releases?

No. That would be very confusing, as the stable releases are (to
simplify greatly) under the responsability of the security team (ST) and
the stable release managers (SRM), not the LTS team.

> 2) Say "supported by Security team" versus "supported by Freexian",
> instead of just saying "supported by LTS"?

Hm... I'm not sure what that refers to or what you're proposing, but LTS
releases are *not* supported by the security team, but by the LTS team.

> 3) Stop using LTS as a "label" for oldstable releases?

I am not sure how that would help anything. :) I do like, however, the
idea brought by Jeremy Stanley in a reply to your email of using the
"Extended Maintenance" label instead of "Long Term Support" because the
latter is usually attached to a *current* release, while the former is
seen as an *extension*.

But renaming the project seems like a huge undertaking and I'm not sure
it would really resolve this conendrum.

> 4) Just advise users all the time that they should prefer the latest
> stable release, as that is going to have the "latest term support"?

Right. So maybe that's a piece that's been missing in our
communications, and that could be the reason why people still think they
should install jessie cloud images. ;)

So maybe we could make some proeminent statement on the LTS and
LTS/Using pages in the wiki?

> 5) Is that not true anymore with Extended LTS and CIP?

Sorry, what is not true? #4? If so, I think people should *still*
install the latest supported Debian release (stable or stretch right
now) and not LTS or ELTS, when deploying new systems.

I think the idea here is that we think Debian rocks. It's solid, stable,
and we love it. But we want to support it for even longer than what our
volunteer team can deal with right now, so we're hiring a bunch of
dedicated fanatics who can figure out how to fit a square peg in a round
hole for you.

But please don't make us any more square pegs and install Debian
normally. Don't break Debian! :)

https://wiki.debian.org/DontBreakDebian

Thanks!

A.

-- 
Work expands so as to fill the time available for its completion.
- Parkinson's law



Re: Xen 4.4 updates - request for feedback

2018-10-24 Thread Antoine Beaupré
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

2018-10-24 Thread Antoine Beaupré
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

2018-10-24 Thread Antoine Beaupré
On 2018-10-24 11:24:28, Antoine Beaupré wrote:
> On 2018-10-23 14:03:37, Peter Dreuw wrote:
>> Hello, everyone, 
>>
>> I prepared another set of fixes based on the current Xen package on 
>> jessie-security (4.4.4lts2-0+deb8u1, DLA-1549).
>>
>> These fixes include 
>>
>> CVE-2017-15595 / xsa 240 
>> CVE-2017-15593 / xsa 242 
>> CVE-2017-15592 / xsa 243 
>> CVE-2017-16693 / xsa 244 
>> CVE-2017-17044 / xsa 246 
>> CVE-2017-17045 / xsa 247 
>> CVE-2018-10472 / xsa 258 
>> CVE-2018-10981 / xsa 262
>>
>> The testing packages are available here: 
>>
>> https://share.credativ.com/~pdr/xen-test/ 
>
> I'll be reviewing those diffs shortly, thanks!

I've given that a shot and, unfortunately, the actual contents of the
patchset goes over my head, so I cannot provide useful feedback on
those. When I worked on Xen/qemu before, I was content to just adapt the
upstream patches without auditing the fix itself, for what it's worth.

So I have reviewed the patches in that context and they generally seem
to reflect upstreams' intention, for what that's worth.

The only issues I could find were whitespace and shouldn't affect
functionality.

(In XSA-240 [20c8d60a5c], a comment block present in the upstream patch
[0003-x86-dont-wrongly-trigger-linear-page-table-assertion.patch] is
missing. Purely cosmetic. Whitespace noise is introduced in 49721ad27a
which might make future merges needlessly harder. There's a similar
issue in XSA-247 [06d16d9c].)

Again, that's assuming that upstream patchsets backport logically into
4.4. Many XSAs have 4.5 patches (or in some cases 4.6) so it's not that
big of a leap.

Thanks for the hard work!

A.



Re: Xen 4.4 updates - request for feedback

2018-10-24 Thread 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!

> These testing packages are auto generated by our new build system, so the 
> package name is somewhat cryptic as it reflects the date and time of build as 
> well as parts of the git hash it is based on. 
>
> You can find the repository here: https://github.com/credativ/xen-lts 
>
> dpkg might tell you about a potential downgrade, but you can ignore this for 
> testing purposes safely. I expect them to be working but I would appreciate 
> some feedback on this version before passing them to the public repository. 

Did you do any kind of smoke testing or is that something that could be
useful per se?

I always find it tricky to test Xen packages because, well... In what
environment do you test it? Qemu? Xen? Virtualbox? :)

> I will head on to the next issues to fix. 

I'm curious: what is your take on XSA-254 and the Meltdown/Spectre
issues in Xen? Are those fixable?

Should we consider encouraging people to switch to other virtualization
solutions in LTS/jessie considering the difficulty of mitigation in Xen
environments?

Thanks,

A.

-- 
The idea that Bill Gates has appeared like a knight in shining armour to
lead all customers out of a mire of technological chaos neatly ignores
the fact that it was he who, by peddling second-rate technology, led
them into it in the first place. - Douglas Adams (1952-2001)



Re: backported gnutls28 3.3.30 packages availabled for jessie LTS

2018-10-23 Thread Antoine Beaupré
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

2018-10-23 Thread Antoine Beaupré
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

2018-10-23 Thread Antoine Beaupré
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?

2018-10-23 Thread Antoine Beaupré
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



  1   2   3   4   5   6   >