[Tails-dev] Build failed in Jenkins: build_Tails_ISO_feature-jessie #519
See https://jenkins.tails.boum.org/job/build_Tails_ISO_feature-jessie/519/ -- [...truncated 12249 lines...] ERROR: ld.so: object '/usr/lib/libeatmydata/libeatmydata.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. ERROR: ld.so: object '/usr/lib/libeatmydata/libeatmydata.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. ERROR: ld.so: object '/usr/lib/libeatmydata/libeatmydata.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. ERROR: ld.so: object '/usr/lib/libeatmydata/libeatmydata.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. ERROR: ld.so: object '/usr/lib/libeatmydata/libeatmydata.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. ERROR: ld.so: object '/usr/lib/libeatmydata/libeatmydata.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. ERROR: ld.so: object '/usr/lib/libeatmydata/libeatmydata.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. ERROR: ld.so: object '/usr/lib/libeatmydata/libeatmydata.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. ERROR: ld.so: object '/usr/lib/libeatmydata/libeatmydata.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. ERROR: ld.so: object '/usr/lib/libeatmydata/libeatmydata.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. ERROR: ld.so: object '/usr/lib/libeatmydata/libeatmydata.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. ERROR: ld.so: object '/usr/lib/libeatmydata/libeatmydata.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. ERROR: ld.so: object '/usr/lib/libeatmydata/libeatmydata.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. ERROR: ld.so: object '/usr/lib/libeatmydata/libeatmydata.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. ERROR: ld.so: object '/usr/lib/libeatmydata/libeatmydata.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. ERROR: ld.so: object '/usr/lib/libeatmydata/libeatmydata.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. ERROR: ld.so: object '/usr/lib/libeatmydata/libeatmydata.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. ERROR: ld.so: object '/usr/lib/libeatmydata/libeatmydata.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. ERROR: ld.so: object '/usr/lib/libeatmydata/libeatmydata.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. ERROR: ld.so: object '/usr/lib/libeatmydata/libeatmydata.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. ERROR: ld.so: object '/usr/lib/libeatmydata/libeatmydata.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. ERROR: ld.so: object '/usr/lib/libeatmydata/libeatmydata.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. ERROR: ld.so: object '/usr/lib/libeatmydata/libeatmydata.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. ERROR: ld.so: object '/usr/lib/libeatmydata/libeatmydata.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. ERROR: ld.so: object '/usr/lib/libeatmydata/libeatmydata.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. ERROR: ld.so: object '/usr/lib/libeatmydata/libeatmydata.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. ERROR: ld.so: object '/usr/lib/libeatmydata/libeatmydata.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. ERROR: ld.so: object '/usr/lib/libeatmydata/libeatmydata.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. ERROR: ld.so: object '/usr/lib/libeatmydata/libeatmydata.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. ERROR: ld.so: object '/usr/lib/libeatmydata/libeatmydata.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. ERROR: ld.so: object '/usr/lib/libeatmydata/libeatmydata.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. ERROR: ld.so: object '/usr/lib/libeatmydata/libeatmydata.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. ERROR: ld.so: object '/usr/lib/libeatmydata/libeatmydata.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. ERROR: ld.so: object '/usr/lib/libeatmydata/libeatmydata.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. ERROR: ld.so: object
Re: [Tails-dev] [review][website] #9356 warn about char encoding on OpenPGP
Hi, tl;dr: I don't think we need an actual reproducer to document this widely known and understood problem. sajolida wrote (08 Jun 2015 13:42:43 GMT) : [...] I failed to reproduce the problem. I encrypted á ô ü in Tails OpenPGP Applet (both symmetrically and asymmetrically) and the result opened well in Tails OpenPGP Applet, on the `gpg` command line, and in Icedove. The first two results are fully expected if both the sending side and the receiving one are configured to use the same text encoding (and Tails uses UTF-8 both for desktop apps and on the command line). Regarding the third result, just curious (feel free to disregard, as IMO it doesn't really matter, as explained below): how did you send the email that you later opened with Icedove? With Icedove too, or with another email client? 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 ciphertext that's encoded in US-ASCII). In some cases, and even possibly in the majority of cases, it works because the receiving MUA's assumptions are correct, but it cannot possibly *always* work because there's no robust way to correctly guess the encoding of a bytestring in all cases. I'm wrong, I'm sure dkg will happily correct me :) Cheers! ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] [review'n'merge][website] documentation on master branch
emmapeel: sajolida: Maybe I would: * Also mention improvements to the website (other than documentation. Its structure, graphic design, other sections, etc.). I added a new line with links to news and security advisory * Replace 'wiki' by 'website'. I understand from working with new contributors that it's weird to call our website a wiki when it's not really one (from a contributor's perspective). So I think we should progressively stop using the term 'wiki'. Good point! Zoom too high... * Always beware of 'it'. I think you last bullet point would have been clearer for me you said When releasing a new Tails, the branch the release was built from (stable or testing). /me runs to read the Microsoft documentation guidelines again... * Rephrase Translations added to the website into Translations of the website would save you a word :) Ok branch has been updated: ta...@git.tails.boum.org:emmapeel/tails a74f8c8..6c1fbb5 feature/9528-document_master_branch https://labs.riseup.net/code/issues/9528 Merge (with some nitpicking on top), thanks! -- 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 to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] [review][website] #9356 warn about char encoding on OpenPGP
emmapeel: another patch for the documentation, that could solve #9356: Warn that Tails OpenPGP Applet can lead to encoding problems for emails also on the newly reseted branch ta...@git.tails.boum.org:emmapeel/tails * [new branch] feature/9356-warn_openpgp_encoding please give me your suggestions! Thanks for working on this. While reviewing your patch I failed to reproduce the problem. I encrypted á ô ü in Tails OpenPGP Applet (both symmetrically and asymmetrically) and the result opened well in Tails OpenPGP Applet, on the `gpg` command line, and in Icedove. Could you try to reproduce the problem? And I'm very sorry, because I was the one to report it in the first place :P -- 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 to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] [review][website] #9356 warn about char encoding on OpenPGP
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 ciphertext that's encoded in US-ASCII). In some cases, and even possibly in the majority of cases, it works because the receiving MUA's assumptions are correct, but it cannot possibly *always* work because there's no robust way to correctly guess the encoding of a bytestring in all cases. I'm wrong, I'm sure dkg will happily correct me :) Far from it, i was writing up this exact explanation when your message came in. Thanks for writing it :) Furthermore: It's not just about whether your peer's MUA is likely to guess right, and whether a message is *likely* to be interpreted correctly. You also have to evaluate the problem in an adversarial context. If this crucial piece of context (character encoding) is not cryptographically protected, it can be manipulated by an attacker. If the bytestream gets reinterpreted based on the attacker's modifications, what kinds of errors can result? About 30 minutes of fiddling around with malicious character encodings got me to the message tampering through header substitution example here: https://dkg.fifthhorseman.net/notes/inline-pgp-harmful/ It's not a world-shattering break, but it's clear that the context does need to be protected in order for messages to be safely transmitted. Inline PGP has no way to do that. --dkg ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
