On 04/12/14 21:16, Oliver-Tobias Ripka wrote:
According to anonym on Thu, Dec 04 2014:
FWIW I experienced no issues during my tests with *only* ESTABLISHED in
both the INPUT and OUTPUT chains so neither NEW nor RELATED seems
essential for the basic usage I tested. And of course the above
anonym:
* 2015-01-13, late (CET)?
* 2015-01-14, early and afternoon (CET)?
Yeap. I'd prefer be doing other things on these days and happily skip
this testing session... But as very few other people show up lately, I
might have to help you guys again, and it's no big deal.
--
sajolida
Hi anonym,
was it intentional that this has not been sent to tails-testers@b.o ?
So, testers, please let me know if you are available on:
* 2015-01-13, late (CET)?
* 2015-01-14, early and afternoon (CET)?
Cheers!
u.
___
Tails-dev mailing list
On 11/12/14 12:51, u wrote:
was it intentional that this has not been sent to tails-testers@b.o ?
Yes. The testing I'm talking about here is internal testing of a final
stable release, with trusted participants only. We ask for help from
tails-testers@ by announcing release candidates there, and
According to anonym on Thu, Dec 11 2014:
So, in addition to proto tcp, how does --syn compare to state NEW?
Actually, what is it we are trying to defend against here? Is there any
conceivable attack vector based on sending non-syn packets for
non-ESTABLISHED (i.e. NEW) TCP streams?
Ok...
This is an excellent initiative, for tails, and for all clients on
general/untrusted networks.
Reducing the attack surface (NEW RELATED) has potential impact for any
client/server using
iptables (possibly also firewalld).
Creating a privacy preserving DHCP client is of wide-scale potential
On Wed, 10 Dec 2014 15:20:01 + (UTC)
anonym ano...@riseup.net wrote:
So, testers, please let me know if you are available on:
* 2015-01-13, late (CET)?
If what I did last time (independent testing during the night when most
people are sleeping) is acceptable I can certainly do it again.
Jacob Appelbaum wrote (08 Dec 2014 04:30:06 GMT) :
How are IUK files verified?
https://tails.boum.org/contribute/design/incremental_upgrades/ :)
Cheers,
--
intrigeri
___
Tails-dev mailing list
Tails-dev@boum.org
kurono wrote (09 Dec 2014 20:08:28 GMT) :
I am sending a patch again, since I could not access the repo (It does
not recognize my public key, maybe its my fault :/).
I think you need to initialize it by pushing something to it once,
before you can fetch from your repo.
Besides, I am not
sure
anonym wrote (08 Dec 2014 09:16:06 GMT) :
I guess what you want is that whenever one of the password fields
are modified we do something like:
if len(auth_password) == 0 and len(test_password) == 0:
self.warning_area_pw_mismatch.hide()
self.warning_area_pw_match.hide()
Ticket: https://labs.riseup.net/code/issues/8420
Branch: doc/8420-tails-boum-frontdesk into master
--
sajolida
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
I am sending a patch again, since I could not access the repo (It
does not recognize my public key, maybe its my fault :/).
I think you need to initialize it by pushing something to it once,
before you can fetch from your repo.
No, I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Jacob Appelbaum wrote:
Hi,
I was recently asked to help someone verify a Tails disk. I
decided to help make a list of hashes and to collect various files
such as iso files, signatures, signing keys and so on:
13 matches
Mail list logo
