Bug #12266
Write release notes for 2.11
100%
Description
They should announce the removal of I2P in Tails 2.12.
Files
Subtasks
Related issues
|
Blocks Tails - |
Resolved | 2017-02-28 |
History
#1 Updated by anonym 2017-02-25 11:19:27
- blocks
Feature #12265: Publicly announce the removal of I2P added
#2 Updated by anonym 2017-02-25 11:20:32
- Assignee set to sajolida
Your availability for these jobs, that you normally do, is not clear to me. Will you be able to do it or should I look for someone else (or perhaps even try it myself!)?
#3 Updated by intrigeri 2017-02-25 16:43:18
> […] or should I look for someone else (or perhaps even try it myself!)?
If help is needed, I believe that spriver and/or I are in a better position than you to do tech writing :)
#4 Updated by anonym 2017-02-28 10:45:58
Ok, so if sajolida do not do this, does anyone of you, intrigeri and spriver, volunteer as a backup?
#5 Updated by spriver 2017-02-28 13:25:47
anonym wrote:
> Ok, so if sajolida do not do this, does anyone of you, intrigeri and spriver, volunteer as a backup?
I never wrote release notes before, but I can try do so (: (at least I can help with reviewing) I should have plenty of time around the release.
#6 Updated by intrigeri 2017-03-01 06:39:16
Great, spriver! IIRC we have doc wrt. how to write release notes. I should be able to review your work, but it’ll depend on timing.
- anonym, when do you expect the changelog to be drafted?
- Based on the above: spriver, when do you expect you’ll have draft release notes?
#7 Updated by spriver 2017-03-03 08:58:12
Indeed, there is doc and a template for creating the release notes.
I’ll have time this weekend to write a draft wrt. removing I2P. AFAIK, I can do the rest of the release notes soonest when the changelog is ready, right?
#8 Updated by intrigeri 2017-03-03 09:01:37
- Assignee changed from sajolida to spriver
> I’ll have time this weekend to write a draft wrt. removing I2P.
Great! Note that feature/12271-i2p-removal-notification (that I’ve just merged into stable) introduces some text that could be reused.
> AFAIK, I can do the rest of the release notes soonest when the changelog is ready, right?
Yes.
#9 Updated by sajolida 2017-03-04 20:42:05
The release is scheduled on the first day I’ll be at IFF. I could be
able to write the release notes on Monday while travelling there.
Otherwise, I’m happy to let spriver work on that!
#10 Updated by anonym 2017-03-05 09:55:35
intrigeri wrote:
> * anonym, when do you expect the changelog to be drafted?
Normally this happens on Monday, since that’s when I follow release_process.mdwn, and the changelog generation is part of it. I could do it earlier, upon request (so if you want it, spriver, just let me know).
spriver wrote:
> I’ll have time this weekend to write a draft wrt. removing I2P.
I2P will be removed in Tails 2.12, not in 2.11!
> AFAIK, I can do the rest of the release notes soonest when the changelog is ready, right?
Yes, but if you want a partial changelog earlier, like I said, just ask.
#11 Updated by intrigeri 2017-03-05 10:12:39
- Assignee changed from spriver to anonym
- QA Check set to Info Needed
It seems that commit:442a293d896076a1a8242d8d4f3320dc016495bb fixes a serious security issue that’s been present since we introduced MAC spoofing. Right? I would like to see a minimal analysis of the impact, that we can translate into the security advisory against 2.10 (IMO it’s our duty to communicate clearly when we discover flaws in protections we were trying to offer).
I’ll focus on the network drivers blacklist here, assuming that the other blacklisted modules are no big deal (but please double-check). So, in 2.10:
- Can these modules be auto-loaded by the kernel during the boot process? Or only later when I plug a new network adapter later on?
- What exact situations are affected? I guess at least the offline mode, and the MAC spoofing failure safety net. Plus maybe some more depending on the question above. Anything else?
- What’s the impact given the other mitigations we have in place? IOW, are the other safety nets we have enough to:
- guarantee that no IP network connection will be set up in offline mode / when MAC spoofing fails? (of course this says nothing about lower-level things that this very blacklist scheme was meant to protect against, e.g. drivers sending packets themselves, before the MAC is spoofed)
- mitigate the impact of security issues in blacklisted modules, that could potentially allow an adversary who got arbitrary code exec as amnesia to escalate to root?
(If I were mean, I would mention that problem in the “Tails’ MAC ‘leak prevention’ question” thread, where I proposed a while ago to remove the blacklist approach :P)
#12 Updated by anonym 2017-03-05 12:19:53
- File 0001-Test-suite-make-sure-Disable-network-works-for-netwo.patch added
- Assignee changed from anonym to spriver
- QA Check deleted (
Info Needed)
intrigeri wrote:
> It seems that commit:442a293d896076a1a8242d8d4f3320dc016495bb fixes a serious security issue that’s been present since we introduced MAC spoofing. Right?
tl;dr: I don’t think there has been a security issue here.
It seems blacklist MODULE is enough to block MODULE from automatically loading when plugged, since udev (“usually”) runs modprobe with the --use-blacklist option (see man 8 modprobe). That is in contrast to e.g. opening a DCCP socket, which will autoload the dccp module. In other words, udev respects blacklist at all times, but the kernel’s auto-loading mechanism does not (which makes sense, since it has no concept of /etc/modprobe.d).
> I would like to see a minimal analysis of the impact, that we can translate into the security advisory against 2.10 (IMO it’s our duty to communicate clearly when we discover flaws in protections we were trying to offer).
>
> I’ll focus on the network drivers blacklist here, assuming that the other blacklisted modules are no big deal (but please double-check). So, in 2.10:
>
> * Can these modules be auto-loaded by the kernel during the boot process? Or only later when I plug a new network adapter later on?
For the reason I detailed above, I don’t think the blacklisted network modules can be automatically loaded at all. I implemented an automated test (see attached patch) which seems to confirm this (I checked out the 2.10 tag, applied the patch, and ran against the 2.10 ISO). I’d appreciate if someone with access to a real USB dongle could give it a shot on real hardware. Any one?
If I am correct I think all your other points irrelevant, so let’s only look at them if someone manages to contradict me (e.g. with a test on real hardware).
#13 Updated by intrigeri 2017-03-05 13:42:48
> tl;dr: I don’t think there has been a security issue here.
Good. In other words, the commit we’re discussing was “just in case we’re missing something else that could go wrong”, right?
#14 Updated by anonym 2017-03-05 13:49:33
intrigeri wrote:
> > tl;dr: I don’t think there has been a security issue here.
>
> Good. In other words, the commit we’re discussing was “just in case we’re missing something else that could go wrong”, right?
It was for completeness and consistency since that’s what we must do for e.g. the dccp module. TBH the security angle didn’t occur to me; I didn’t know udev respects blacklist, but I did carefully test plugging a USB dongle with a blacklisted module when I wrote this code for the MAC spoofing feature and it worked then.
Any way, case closed!
#15 Updated by anonym 2017-03-06 13:32:04
I’ve pushed the 2.11 changelog to the stable branch.
#16 Updated by spriver 2017-03-07 06:25:13
- Assignee changed from spriver to anonym
- QA Check set to Info Needed
- Feature Branch set to spriver:web/tails-2.11-release-notes
I pushed a first draft of the release notes. I don’t have the the ‘Details’ section of the security holes news populated so far, as I don’t know if I have to search manually for every single fixed CVE from the security fixes in debian/changelog.
#17 Updated by anonym 2017-03-07 13:56:38
- Assignee changed from anonym to spriver
- QA Check changed from Info Needed to Dev Needed
spriver wrote:
> I pushed a first draft of the release notes. I don’t have the the ‘Details’ section of the security holes news populated so far, as I don’t know if I have to search manually for every single fixed CVE from the security fixes in debian/changelog.
Yes, you have to do it manually and I haven’t automated this since one essentially has to read the DSAs any way to make sure everything is correct, and while doing so I save the (package, DSA) pair in a convenient manner for writing the security notice later. It could be automated, I’m sure, but I bet it will be complex and possibly error prone.
Any way, your security notice looks good, except for linux. See: https://www.debian.org/security/2017/dsa-3791. As you can see, it says “these problems have been fixed in version 3.16.39-1+deb8u1”, which we are not using. This DSA is from 2017-02-22, but the linux version we use is (ignoring a few minor releases which doesn’t add much) from 2016-12-16, so it’s highly unlikely all the issues from the DSA are fixed. In this instance we should only reference CVE-2017-6074 as fixed for linux.
This, and a few other issues (also in the release notes) are fixed in the web/tails-2.11-release-notes branch — please merge it into yours, and let me know when you are done!
#18 Updated by spriver 2017-03-07 15:38:26
- Assignee changed from spriver to anonym
- QA Check changed from Dev Needed to Ready for QA
Thanks for your changes, sorry that I did not look too exactly at the Linux CVE. I made two minor additional changes and pushed them.
Twitter draft: Tails 2.11 is out: https://tails.boum.org/news/version_2.11.
#19 Updated by anonym 2017-03-07 17:28:53
- Status changed from Confirmed to Fix committed
- Assignee deleted (
anonym) - % Done changed from 0 to 100
- QA Check changed from Ready for QA to Pass
Great job, spriver! Your words shall be read by thousands of people! :)
#20 Updated by anonym 2017-03-09 13:59:07
- Status changed from Fix committed to Resolved