On Sun 2020-11-08 09:24:13 +0100, intrigeri wrote:
> I would fully agree with this line of reasoning if the requested tool
> (steghide) provided a nice UX for folks who are not particularly
> tech-savvy. Unfortunately, it's a CLI tool. So it seems to me that
> using steghide is harder, for most of
On Thu 2020-10-29 14:49:20 +, proc...@riseup.net wrote:
> There's always a difficulty in finding a willing maintainer to sponsor
> packages. @DKG if you can assist with that, then hopefully it would seal
> the deal before stable next freeze. Thoughts?
Sorry, i don't have the bandwidth to
On Wed 2020-10-28 15:56:43 +, proc...@riseup.net wrote:
> Is Debian inclusion a hard blocker? We've been maintaining a deb package
> for a couple years now that's updated when upstream is.
why not submit that .deb for inclusion in debian directly then? that
makes it easily available to
On Mon 2020-10-26 08:39:06 +0100, intrigeri wrote:
> At this point of the conversation, I would recommend users for whom
> this matters a lot to install their preferred steganography tool
> by hand (without Additional Software) whenever they need it, so that
> it leaves no traces and such
On Thu 2019-11-21 11:49:53 +0100, u wrote:
> Oh my! That's pretty cool:
>
> On Debian Planet: https://bisco.org/notes/converting-ikiwiki-to-hugo/
>
> With regard to the translation platform and the Linguine effort, there
> were a lot of ideas about moving to another static site generator which
>
On Sun 2019-10-20 19:29:39 +0200, intrigeri wrote:
> I've tried in a development image that should be pretty close to
> Tails 4.0 with this APT source:
>
> deb tor+https://deb.torproject.org/torproject.org/ buster main
>
> … and it worked out of the box. So it looks like what you need will
> come
On Fri 2019-05-03 12:45:17 +0200, intrigeri wrote:
> When we switch to Wayland (#12213) we'll need to change the way we run
> the Unsafe Browser. In particular, we won't be able to run it under
> a dedicated user anymore.
this seems problematic to me. dedicated user accounts are one of the
Thanks to everyone for talking through the details.
On Fri 2019-03-22 15:47:23 +0100, Nicolas Vigier wrote:
> With the current version of the extension, I don't know if it makes a
> big difference. However if there was some plan to improve the extension
> to make it verify gpg signatures, then
On Sun 2019-03-24 11:36:11 +0100, intrigeri wrote:
> Thoughts?
>
> I'll be happy to implement this proposal.
I'm not a regular contributor, so you should weight my opinion very
lightly, but this all sounds quite to me.
The more i see technical systems in actual use, the more i think that
simpler
hi all--
thanks for bringing this discussion, and your reasoning for it, to the
broader community.
On Wed 2019-03-20 14:25:50 +0100, u. wrote:
> We know from Javascript statistics of our download page that roughly
> ~20% of the downloads of Tails images are verified by users using the
>
hey folks--
i played around with augmenting a tails 3.12.1 installation today by
adding an external apt repository, and found that i needed to add
apt-transport-https (the repo in question was https-only). But
apt-transport-https doesn't actually work on Tails 3.12.1, because it's
not
On Thu 2018-11-01 12:58:21 +0100, intrig...@boum.org wrote:
> anonym has reported similar issues but he cannot see them if he uses
> the IP address directly, which seems to confirm the hypothesis of
> overenthusiastic DNS caching on exit nodes. Nothing we can do about
> exit nodes whose DNS
On Wed 2018-07-25 05:52:40 +0200, Sebastian Nielsen wrote:
> The problem it would solve, is that you can avoid having a persistent
> partition alltogether, but still allow users to be able to use PGP
> encryption and SSH keys and similiar. By simply determisticly generating
> them out of a
Hi Intrigeri and tails folks--
I'm really glad you're thinking about protected headers! sorry for the
lag in this, much of which appears to be attributable to me :/
On Mon 2018-02-19 12:00:12 +0100, intrigeri wrote:
> At a recent [Tails meeting] we've decided to tweet ([Tails ticket])
> about
On Mon 2017-01-02 14:46:30 -0500, intrigeri wrote:
> Now, taking a step back, I wonder: why does why GRKERNSEC_KMEM
> disables kexec?
>
> Is it because it's deemed dangerous in itself? Then perhaps it's be
> worth asking grsec people if they'd be open to controlling the kexec
> part with a more
On Fri 2016-08-26 14:50:12 -0400, intrigeri wrote:
> Since then, NetworkManager gained the ability to randomize MAC
> addresses [1]. If we delegate the bulk of the work to it, then this
> becomes:
>
> a) We remove the modules blacklist logic.
> b) We set up a boot-time firewall that blocks all
On Wed 2016-06-08 18:03:21 -0400, Anonymous wrote:
> I would like to fill remaining space on DVDR from /dev/random
> after I have burned the Tails 2.4 ISO.
This is a strange request, and i don't think it accomplishes the goals
you're setting out to accomplish. I'm not even sure the goals you're
On Mon 2016-04-04 10:27:53 -0300, emmapeel wrote:
>A. Point people from the direct download to a simpliflied version
>of the GPG instructions (without all the Web of Trust information)
>to satisfy scenario #1.
If your recommendations here are intended to be as simple as possible
(no
On Thu 2016-03-17 14:59:15 -0400, intrigeri wrote:
> Daniel Kahn Gillmor wrote (17 Mar 2016 16:20:31 GMT) :
>> It's also possible that some default GNOME shell stuff requires fancier
>> graphics capabilities than some hardware provides. i believe gnome
>> classic doesn't have
On Thu 2016-03-17 08:41:42 -0400, anonym wrote:
> Are you sure there would be no other changes? IIRC pure GNOME Shell deal
> with switching between applications (think: alt+tab) in a "novel" way.
It's also possible that some default GNOME shell stuff requires fancier
graphics capabilities than
On Sun 2016-03-13 08:52:03 -0400, intrigeri wrote:
> I hereby propose that we:
>
> 1. acknowledge we have not been able, so far, to properly maintain
>custom Ciphers and MACs settings for the OpenSSH client;
>
> 2. acknowledge that our failure at #1 has been causing both usability
>and
On Wed 2016-02-03 07:34:16 -0500, sajolida wrote:
> Shall we do this too?
Yes, anyone using git who cares about object integrity should probably
set transfer.fsckobjects to true globally.
Thanks for raising this here. hopefully we can get this to be the
default upstream soon.
--dkg
On Mon 2016-01-25 10:07:06 -0500, random_u...@airpost.net wrote:
> - In order to rule-out an error during the writing from ISO to USB
> stick, I repeated the entire process a second time. The result was the
> same: the hashes for /dev/sdX (the partition containing the installed
> ISO) do NOT match
On Tue 2016-01-05 10:51:52 -0500, GoodCrypto Support wrote:
> Message forwarded from tails-b...@boum.org
>
> > could you contact the dev team at tails-dev@boum.org about the script you
> are proposing ?
>
> Sometimes for days we can't get an htpdate time sync in tails. Because we
>
On Tue 2015-12-01 20:06:01 +0200, Donncha O'Cearbhaill wrote:
> You can boot Tails fully into RAM which allows your to remove the USB
> stick. Press tab at boot to get into the boot options, the provide
> 'toram' as an option.
cool, thanks for the tip.
How much RAM is required on the host
On Wed 2015-12-02 01:11:51 +0200, Austin English wrote:
> On Tue, Dec 1, 2015 at 4:56 PM, Daniel Kahn Gillmor
> <d...@fifthhorseman.net> wrote:
>> On Tue 2015-12-01 20:06:01 +0200, Donncha O'Cearbhaill wrote:
>>
>>> You can boot Tails fully into RAM which allows
On Mon 2015-09-14 18:21:37 -0400, Liste wrote:
> To use OnionMail in TAILS you need only this:
> https://onionmail.info/network/wizard.tar.gz
> http://louhlbgyupgktsw7.onion/network/wizard.tar.gz
>
> Don't use this:
> https://github.com/onionmail/onionmail-wizard
>
> This is the right sources
Hi! thanks for reporting this. I'm afraid i find this report rather
breathlessly scary-sounding but short on concrete details that i can
understand. It's possible i'm just ignorant. Please enlighten me.
Specific requests for clarification follow.
On Tue 2015-07-07 11:15:15 -0400, Dr.
On Fri 2015-06-26 13:40:51 -0400, sajolida wrote:
The Claws Mail bug is getting a solution in the case of queued emails:
http://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=2965
I'm glad to see this being addressed upstream!
What would be the next steps for us to take
On Fri 2015-06-12 15:13:18 -0400, Georg Koppen wrote:
We actually rebuilt parts of the 4.5.2 bundles mentioned above to
include the latest Tor (0.2.6.9) and above all a fixed OpenSSL (1.0.1n).
Please use OpenSSL 1.0.1o, and not 1.0.1n.
1.0.1n had an ABI breakage which was fixed in 1.0.1o.
On Wed 2015-06-10 15:07:17 -0400, bancfc wrote:
The Hidden Service descriptor proposal didn't make sense so we query
Hidden services directly and extract timestamps from their HTTP headers.
Which hidden service operators do you query? what counts as a
reputable Onion Site ? Do those
On Mon 2015-06-08 10:32:18 -0400, intrigeri wrote:
Anyway: the root cause of the problem is PGP/inline, and it's a real
one (as explained in the thread that lead to this bug being filed
IIRC, the sending MUA has no way to express what's the encoding of the
cleartext, because it only sees the
On Fri 2015-06-05 10:58:55 -0400, sajolida wrote:
intrigeri:
the Tor Browser dev team is preparing a 4.5.2 release to fix Logjam.
GeKo tells me that the fix for ESR landed last week but mozilla does
not deem that important enough to make a chemspill and so we
basically cherry-picked the
On Sat 2015-05-30 04:22:00 -0400, intrigeri wrote:
Daniel Kahn Gillmor wrote (29 May 2015 15:51:09 GMT) :
i'd also be fine with only reserving (targeting
for non-immediate changes) a.b, and treating any a.b.c release as an
intermediary release.
This would remove the ability to distinguish
On Fri 2015-05-29 11:19:17 -0400, intrigeri wrote:
it popped up to my mind that our current versioning scheme is a bit
painful whenever we need to insert an unexpected release: e.g.
when we've put out 1.3.1, it stole a version number that was
reserved, which can result in some confusion, e.g.
On Fri 2015-05-08 14:56:13 -0400, intrigeri wrote:
I trust SSH remote host authentication much more than I trust whatever
library + certificate authorities bundle Git is using for HTTPS.
Understood :) I just don't like authorizing use of my secret key
material in cases where i don't need to, so
The Tails documentation about MAC addresses talks about the first six
bytes and the last six bytes, but MAC addresses are six bytes
total, and the OUI and NIC parts are actually three bytes each.
This should be fixed by saying six nybbles, six hex characters, or
three bytes. I've opted for the
There is no need for developers with write access to clone
publicly-visible repositories over ssh.
Instead, developers can clone the publicly-visible repositories like
everyone else does, and can just update the pushurl, so that pushes
are sent over ssh, while pulls don't require access to the
Hi folks--
I was looking at an old Tails instance i've had around for a while with
a persistence volume containing ~/.gnupg from back around tails 0.21 or
so.
i found that talking to the keyservers via gpg --search dkg was
failing.
Looking deeper, i noticed that ~/.gnupg/gpg.conf contained:
On Tue 2015-03-03 21:01:55 +0100, intrigeri wrote:
[@dkg: I know you read the last, but in this email there's one
question for you, and I would be sad if you missed it, so Cc'ing you
explicitly. Look for your handle below.]
thanks for the explicit callout, this thread has been mostly off my
On Fri 2015-02-27 06:23:17 -0500, intrigeri intrig...@boum.org wrote:
Jeff Anderson wrote (24 Feb 2015 03:54:31 GMT) :
I was using Claws with PGP MIME. I am setup to use IMAP (not POP). I
prepared a message and set it to encrypt the content. Then I selected Send
Later. The message went into
On Thu 2015-02-19 06:25:35 -0500, intrigeri wrote:
Hi,
Daniel Kahn Gillmor wrote (18 Feb 2015 23:50:20 GMT) :
On Wed 2015-02-18 16:24:51 -0500, goupille wrote:
iteration time: it is low for slow systems, and Tails is aimed to work
on relatively slow systems it should be increased
iteration
On Wed 2015-02-18 16:24:51 -0500, goupille wrote:
we received complaints from a user about the persistence
encryption. basically, I don't really know what I'm talking about, so
that's a resumee of that user's remarks (without the bad words) :
AES : the fact that moderns hardware are shipping
On 12/28/2014 07:03 PM, Alan wrote:
Please find below a blog post proposal.
Thanks for this, Alan. I would be happy to see it published. A couple
native-english-speaker suggestions below:
You are into GNOME development and want to participate to Tails?
This should be Are you into...?
You
On 12/04/2014 10:37 AM, Jacob Appelbaum wrote:
On 12/4/14, Daniel Kahn Gillmor d...@fifthhorseman.net wrote:
I'm not sure i'd characterize a simple DHCP client as quite straight
forward, but certainly minimalist one is more straightforward than one
which handles all the possible extensions
On 12/04/2014 09:56 AM, Jacob Appelbaum wrote:
I'm currently working with a friend on a privilege separated dhcp
client that does not need raw sockets. It is in the early stages but
it is able to do the network lease without being root and without
having a raw socket. It is surprising that
On 11/06/2014 09:49 AM, intrigeri wrote:
Michael Rogers wrote (06 Nov 2014 12:41:53 GMT) :
If the USB stick is written manually using isohybrid and dd, is it
still the case that different devices would have different
fingerprints, or is it only an issue for USB sticks created with the
Tails
Hi good Tails people--
I had a Tails stick which i had upgraded successively from at least 1.1
to 1.2. I found that after booting 1.2, unsafe-browser no longer works.
If i click to launch it, it appears to try to start (the confirmation
dialog box showed up), but no browser window ever opens.
Hi Intrigeri--
On 11/01/2014 04:02 PM, intrigeri wrote:
Daniel Kahn Gillmor wrote (01 Nov 2014 19:11:46 GMT) :
I had a Tails stick which i had upgraded successively from at least 1.1
to 1.2. I found that after booting 1.2, unsafe-browser no longer works.
If i click to launch it, it appears
On Tue 2014-10-21 11:16:20 +0200, intrigeri wrote:
hokey lint's output is also, I would argue, way easier to understand
and draw conclusions from; colors help. So, basically, `hokey lint' is
IMO the best available tool right now for anyone to do a lot of basic
sanity checks on their keys. It's
On 09/27/2014 10:31 AM, Clement Hermann wrote:
as part of my work on Tails OpenPGP Apllet to make it suitable for
Debian, I found out the icons were licensed under CC-BY-SA 2.0, which is
not DFSG compliant.
I wasn't aware that CC-BY-SA is not DFSG compliant -- or is it just the
older version
On 09/27/2014 05:55 AM, Griffin Boyce wrote:
But to your point, local system time doesn't/shouldn't impact correlation
attacks at all. Every network hop between the user and destination has a set
system time that is far better to determine sequence. Correlation attacks are
nice on paper,
---
wiki/src/doc/first_steps/installation/manual/linux.mdwn | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/wiki/src/doc/first_steps/installation/manual/linux.mdwn
b/wiki/src/doc/first_steps/installation/manual/linux.mdwn
index acbefb2..9a679e4 100644
---
Hi Tails folks--
Christian Huitema recently did a privacy review of DHCP, spurred by the
privacy discussions with the IETF. It's worth reading his descriptions:
https://tools.ietf.org/html/draft-huitema-perpass-dhcp-identifiers-00
This was written in response to a call from Stephen Farrell to
On 07/10/2014 11:14 PM, dar...@unseen.is wrote:
Hi Tails Dev team please integrate GoldBug - Secure Instant Messenger.
Secure P2P Instant Messaging Chat from Friend to Friend without relying
on a central server.
I have not reviewed GoldBug myself (the only source tarball i could find
in 5
On 06/24/2014 06:56 AM, Jacob Appelbaum wrote:
[snip interesting discussion of user-agents for human-driven HTTP clients]
As for the system itself - I looked at `apt-get update` and found the
following user agent during a fetch:
GET /debian-backports/dists/squeeze-backports/Release.gpg
On 05/29/2014 07:47 AM, Chamelephon wrote:
It is gonna affect the whole privacy-minded world, not just the tails
community. But as a matter of fact, TAILS doesn't use truecrypt in any
fashion.
Actually, if you boot tails with the truecrypt argument, tails will
make truecrypt available to the
I've tried booting a Lenovo Thinkcentre M82 (bios 9SKT58AUS and also
9SKT79AUS) with tails 0.23 and 1.0 (both alpha generations, made on
linux, and beta generations, made with Tails installer). I configured
the bios so that it could boot from USB, and so that it would boot in
legacy mode.
On 05/02/2014 02:10 PM, Daniel Kahn Gillmor wrote:
I've tried booting a Lenovo Thinkcentre M82 (bios 9SKT58AUS and also
9SKT79AUS)
[...]
http://nightly.tails.boum.org/build_Tails_ISO_feature-uefi/tails-i386-feature_uefi-1.1-20140429T0733Z-02a2adf.iso
(sha512sum
On 04/28/2014 02:44 PM, intrigeri wrote:
We have on our roadmap to Tails 2.0 to replace TrueCrypt (that can
currently be installed, in an opt-in way, at Tails boot) with
something that suit our taste better:
https://tails.boum.org/blueprint/replace_truecrypt/
see
https://mailman.boum.org/pipermail/tails-dev/2014-April/005599.html
for more discussion.
---
wiki/src/support/known_issues.mdwn | 6 ++
1 file changed, 6 insertions(+)
diff --git a/wiki/src/support/known_issues.mdwn
b/wiki/src/support/known_issues.mdwn
index fa14cd0..d01b935 100644
---
I've tested Tails 0.23 with the Dell Latitude E6430, BIOS versions A09
and A11 and seen this same misbehavior. It turns out that you can
just hit enter, though, and the machine will continue to boot from the
USB stick despite this warning message.
---
wiki/src/support/known_issues.mdwn | 5 -
62 matches
Mail list logo
