Commit f51c79b7 authored by amnesia's avatar amnesia
Browse files
parents 77d50bc5 505b9f98
......@@ -44,3 +44,20 @@ that a bunch of hopefully useful messages are displayed on boot.
Then try to boot again, and append the end of the boot log (or what
seems to be relevant to your problem) to your bug report.
No internet access
The WhisperBack bug reporting tool (accessed from the Tails desktop)
can of course not send the bug report when there is not internet
access. The following steps can be used as a work-around (Note that
your bug report will not be anonymous unless you take further steps
yourself (e.g. using Tor with a throw-away email account)):
1. In Tails, start the bug reporting tool
2. In the bug report window, expand "technical details to include"
3. Copy everything in the "debugging info" box
4. Paste it to another document (using gedit for instance)
5. Save the document on a USB strick
6. Boot into a system with working networking and send the debugging
info to us.
In Tails 0.8-rc1, sdmem on eject works when booting from USB, but has
no visible effect when booting from CD.
The problems seem to have something to to with udev not sending events
(e.g. the "change" uevent we wait for) until the device is unmounted.
The following was tested on a secondary CD-ROM drive (so not the boot
device which may or may not invalidate this theory):
1. Insert a CD in the seconday CD-ROM drive (say it's /dev/sr1) and
mount it.
2. Run: udev-watchdog <udev path for /dev/sr1> cd
3. Eject the CD.
4. Observe that the watchdog sees nothing and that the device remains
mounted. Trying to access the mounted filesystem will produce I/O
4. Run: umount /dev/sr1
5. Observe that the watchdog finally sees the "change" action.
Furthermore, in lack of hardware, I tested this in VirtualBox, which
may behave different than real hardware. So YMMV.
When building 0.8-rc1 with the stable kernel (2.6.32-5-486) this issue
does not arise, which suggests that the issue is with the linux kernel
and was introduced somewhere after 2.6.32. Otoh, on my up-to-date
wheezy system (linux 3.0.0-1-amd64, udev 172-1, etc.) I do not have
this issue using udev-watchdog, wich could suggest a compatibility
issue with some other package (we also have i386 vs amd64, of course).
Updating to unstable's udev (172-1) in hope of it playing better with
linux 3.0.0-1 from unstable did not solve the issue either, however.
> Indeed, linux 2.6.38-rc1 [reworked disk event handling|]
> so now we need to set block.events_dfl_poll_msecs (to 1000, for
> instance) until the drivers are updated accordingly.
Fixed in commit f4d6f6870167313cc19514fa95b9b69de47bac8f => [[done]]
......@@ -171,3 +171,19 @@ Empathy
- cannot connect to a XMPP server running behind a hidden service (2.30.3-3)
- Link-local XMPP connection manager ([[!debpkg telepathy-salut]]
0.5.0-3) does not support voice calls
- [homepage](
- allows to use zRTP on other VoIP software
- supposed to work with Ekiga
- some packages in Debian: libzrtpcpp-1.6-0, is that enough?
- last release was a public beta, out in March 2009
- license seems inadequate: according to [[!wikipedia Zfone]],
"only the libZRTP SDK libraries are provided under the AGPL. The
parts of Zfone that are not part of the libZRTP SDK libraries are
not licensed under the AGPL or any other open source license.
Although the source code of those components is published for peer
review, they remain proprietary. The Zfone proprietary license also
contains a time bomb provision."
[[!tag todo/wait]]
Do we want to keep the CS Lite addon?
No other cookie manager is packaged in Debian yet. If we want to keep
it, we should package this one or similar. Someone filed an ITP for
it: [[!debbug 636399]].
Also, [Cookie
Monster]( seems much
better than CS Lite => we asked for it to be packaged in Debian in
[[!debbug 623970]], which was ITP'd but not uploaded yet.
better than CS Lite, aka. maintained and nicer UI; it's been uploaded
to Debian recently ([[!debbug 623970]]). Let's switch to it.
> Branch `feature/cookie-monster` installs Cookie Monster instead of
> CS Lite. Now needs to be built, tested, and likely configured.
[[!tag todo/code]]
If in the end we want to keep CS Lite, we should package this one or
similar. Someone filed an ITP for it: [[!debbug 636399]].
CS Lite features
......@@ -25,4 +25,24 @@ of those. Waiting for the software to mature a bit would seem sound.
What set of notaries should we use?
What set of notaries should Tails use by default?
### Tor hidden services
At least one configured notary must be able to validate certificates
for web servers running behind Tor hidden services, i.e.
https://xxxxxxxxx.onion. Maybe better to ship a separate Iceweasel
profile dedicated to this kind of browsing, that would use
[[todo/Monkeysphere]] instead of Convergence.
Captive portals
When we'll implement [[support wifi hotspots with captive
portals|todo/add_support_for_free_wifi_hotspots]], the webbrowser
configuration dedicated to this task probably need to **not** use
Convergence, as the Convergence client would not be allowed to reach
the notaries.
......@@ -62,6 +62,13 @@ See also the `mozilla/security/nss/lib/ckfw/builtins/README` file in
the `nss` package source tree to learn how to build a ``
with a custom list of builtin CAs.
According to [a blog
`certutil` may be an adequate tool for the task:
apt-get install libnss3-tools
certutil -d $HOME/.mozilla/firefox/$HLAGHLLAGHGAAHLGALHHGHLAGH.default -A -n 'CA Cert Signing Authority - Root CA' -t CT,C,C -i /etc/ssl/certs/root.pem
What does not work is to disable this module for the no-CAs profile
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment