[Tails-dev] 2.0~rc1: Installed Partition Hash does Not Match That of ISO
Hello, I have found a difference concerning the manual installation to USB between Tails 2.0~rc1 and previous versions of Tails (including the last stable release, 1.8.2). With the previous versions, I would always find that the checksums (sha256;sha1;md5) of the partition of the installed ISO (/dev/sdX) would match the checksums of the ISO that I had downloaded (and verified the signature of). Now, after manually installing Tails 2.0~rc1 onto a USB stick, I have found that the checksums of the Tails partition do NOT match those of the ISO. Please note the following relevant facts concerning this discrepancy: - In all cases, I had verified the ISO against its signature before installing it to USB - 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 the hashes for the ISO - The USB stick that I used for the install is one that I have used many times previously, without issue, to install past releases of Tails-- including 1.8.2 - The OS and hardware that I used were also the same Any ideas? ___ 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.
[Tails-dev] Help: GNOME Shell integration issue affecting Tails
Hi, Carlos Soriano Sanchez suggested I re-sent my call for help on the GNOME Shell list, so here we go. Please keep me Cc'ed, I'm not subscribed to gnome-shell-l...@gnom.org. I am a contributor to the Tails project (https://tails.boum.org/), a live system aimed at preserving its users' safety, privacy and anonymity, focusing on ease of use for non-technical users. To give you an idea of the impact of the problems I'm asking for help here, we're talking about a system that is started more than 17,000 times a day. We are about to release Tails 2.0 in a few days. It will be our first release based on Debian 8 (Jessie), and more to the point here, our first release that includes GNOME Shell as the default (and only) desktop environment. Woo! There's a glitch though: during the beta and RC phases, many testers reported to us serious bugs with how icons in the top-right tray are displayed. Probably relevant is the fact that we include the topIcons extension (because not all the important status icons have been migrated to more modern GNOME technologies yet). But not only icons moved by topIcons to the top-right tray are affected. TBH, I personally came to the conclusion that the bug most likely lives in the topIcons extension. I can very well understand if you see it as none of your business for this reason, and I have reported it to this extension's author already. Still, we're in a hard place on our way to ship GNOME Shell right now, because sadly, nobody on our team has the skills to debug this problem, so we help from any skilled people would be much appreciated. The symptoms we see are: * Widgets in the top-right tray are somewhat narrowed (to their arrow, with a dot instead of the expected text); I've seen this happen at least for the date/time and the ibus menu icon: https://labs.riseup.net/code/attachments/download/1186/new-session.png https://labs.riseup.net/code/attachments/download/1180/1.png https://labs.riseup.net/code/attachments/download/1181/2.png https://labs.riseup.net/code/attachments/download/1182/3.png https://labs.riseup.net/code/attachments/download/1183/4.png * The clickable area and the icon of a widget moved by topIcons are not at the same place. For example, nothing happens when I click on the Florence icon, but Florence appears when I click elsewhere (on the left of the OpenPGP Applet). This screenshot shows what is the clickable area for Florence at this point: https://labs.riseup.net/code/attachments/download/1173/clickable%20area.png Enabled extensions: * Classic mode extensions: apps-m...@gnome-shell-extensions.gcampax.github.com and window-l...@gnome-shell-extensions.gcampax.github.com * topIcons v28 * a custom Tails extension called shutdown-hel...@tails.boum.org: https://git-tails.immerda.ch/tails/tree/config/chroot_local-includes/usr/share/gnome-shell/extensions/shutdown-hel...@tails.boum.org?h=testing Other possibly relevant information: * We run GNOME Shell 3.14.4-1~deb8u1 in Classic mode. * The ISO image for Tails 2.0~rc1 can be downloaded from https://tails.boum.org/news/test_2.0-rc1/ — it's a live system, so you can try it out in a virtual machine, after dd'ing it to a USB stick, or burning it to a DVD. * I don't seem to be able to reproduce these bugs with an ISO that has the topIcons extension disabled. It seems that a loaded (or just slow) system exposes the problem more often than a powerful and idling system. * I've seen similar bug reports online elsewhere: https://extensions.gnome.org/extension/495/topicons/ https://www.reddit.com/r/archlinux/comments/2g06t7/icons_disappearing_from_notification_tray_using/ * In an environment (Spice/QXL/QEMU VM) where I can dynamically change the display size & resolution, making the display way bigger fixes the bug, and reverting to the initial display size reverts back to the problematic initial state. * There is one error in the logs that I only see when the bug happens: gnome-session[2343]: (gnome-shell:2871): GLib-GObject-WARNING **: /build/glib2.0-EvFudu/glib2.0-2.42.1/./gobject/gsignal.c:2579: instance '0x94b20f0' has no handler with id '32170' It refers to https://sources.debian.net/src/glib2.0/2.42.1-1/gobject/gsignal.c/?hl=2501#L2579 When this happens, I also see: gnome-session[2003]: (gnome-shell:3042): Gjs-WARNING **: JS ERROR: TypeError: parent is null gnome-session[2003]: onTrayIconRemoved@/usr/share/gnome-shell/extensions/topIcons@adel.gadl...@gmail.com/extension.js:115 * Another piece of logs that we (sometimes) see when the problem happens: gnome-session[30034]: (gnome-shell:30263): Gjs-WARNING **: JS ERROR: TypeError: parent is null gnome-session[30034]: moveToTop@/usr/share/gnome-shell/extensions/topIcons@adel.gadl...@gmail.com/extension.js:135 gnome-session[29844]: (gnome-shell:30074): Clutter-WARNING **: Attempting to add actor of type 'ShellTrayIcon'
[Tails-dev] Requirements for a Pidgin replacement
Hi, Thanks for sharing this! sajolida: the list of properties is interesting. Great list. Communication tools like Trello and Slack are used by Microsoft and the like to make communication tools. Though their employees have zero privacy concerns (: Wordlife, Spencer ___ 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] 2.0~rc1: Installed Partition Hash does Not Match That of ISO
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 the hashes for the ISO If you're using a GNU/Linux system, /dev/sdX (where X is a lower-case letter, like /dev/sdb) is the USB disk itself, and /dev/sdXN (where X is a lower-case letter and N is a number in decimal, like /dev/sdb1) is the partition. Are you talking about the USB stick itself or about some partition on the USB stick? If you're using dd to write the ISO to the USB stick, you'll note that the iso is a different size from the USB stick's volume: du -k tails-i386-2.0~beta1.iso grep sdb /proc/partitions The chances that two bytestreams of different size have the same cryptographic digest should be negligibly small, so it makes sense that the iso and the USB stick have different hashes. I'm surprised you've ever seen that to be the case. > - The USB stick that I used for the install is one that I have used many > times previously, without issue, to install past releases of Tails-- > including 1.8.2 can you repeat the process with the 1.8.2 and verify that they are the same? Maybe you were comparing something different at the time? --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.
[Tails-dev] Tor Browser 5.5 is ready for testing
Hi, Spencer: "No fonts can be relied upon in every linux flavor. " Is this the reason? I am confident that this is the reason (: Wordlife, Spencer ___ 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] 2.0~rc1: Installed Partition Hash does Not Match That of ISO
On Mon, Jan 25, 2016, at 11:01 AM, Daniel Kahn Gillmor wrote: > If you're using a GNU/Linux system, /dev/sdX (where X is a lower-case > letter, like /dev/sdb) is the USB disk itself, and /dev/sdXN (where X > is a lower-case letter and N is a number in decimal, like /dev/sdb1) is > the partition. That is what I meant; the PARTITION of the (USB flash) disk that the Tails ISO was written to, i.e., /dev/sdXN (e.g., /dev/sdb1, /dev/sdc1, etc.) Sorry if I was not clear enough about that. I realized all along that the full device (i.e., full disk) is always larger (and usually much larger) than the ISO and the partition containing the installed ISO (and therefore that the hashes for the full-device will always be different than those for the Tails partition that resides on said device.) For past releases of Tails, the cryptographic checksums (sha256; sha1; md5) for said partition would always match those of the ISO. This allowed me to verify, first, that the write (using dd or cat) had completed without error. Additionally, at any time I wished, I could verify that my Tails partition had not become corrupted by simply generating its hash and then checking that hash against the hash that I knew to be the correct one for the ISO that said partition was written from. (I realize that the second function can still be performed by recording the hash of the Tails partition that was generated immediately after writing said partition to disk and then using said hash as the one to compare against. But since the hash of the partition no longer matches that of the ISO that said partition was written from, I would still be left wondering whether the partition was properly written in the first place AND, even if it was, WHY its hash no longer matches that of the very ISO that it was created from-- as had been the case for me with all past releases of Tails.) Below is the sha256sum I get for the ISO, followed by the one I get for the partition that was written from the ISO. (Note that I verified the ISO against its signature.) sha256sum tails-i386-2.0~rc1.iso 4df44c896a61fc9751463cf3a94d482f1ec0c6d1ae86b270758a2ded544e33d9 tails-i386-2.0~rc1.iso sha256sum /dev/sdX1 3e813eee1d2a38902b31c1180e342237d2c66a36faebe37c065434a10c58fbf0 /dev/sdX1 ___ 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] Requirements for a Pidgin replacement
intrigeri: > sycamoreone wrote (22 Jan 2016 16:04:33 GMT) : >> there has been some desire to replace Pidgin with some other IM client >> (#8573). [...] >> In order to be able to decide when/if a client is a suitable replacement >> for Pidgin, it would be good to have a concrete list of requirements. I >> once started to collect some in a blueprint [...] > > Thanks a lot for raising this, and collecting requirements. > > I'd like to take a step back, since I wonder if we've defined the > problem in a way that we can realistically solve it. Something on the > blueprint suggests the same: "Would a pair of two separate client > (XMPP and IRC) also be okay, or are we only looking for a single > client that can do both?" > > My goal here is to *simplify* the problem to solve, and possibly to > split it into smaller, more reastically solvable problems, as needed. > My goal is definitely *not* to make the problem harder and discourage > those who are working on it already, or would like to join the fun. > > I see five main instant messaging use cases that I would want Tails to > support to some extent: > > A. Contributing to Free Software projects that use IRC chatrooms >(and won't switch to anything else any time soon) > > B. Contributing to Free Software projects that use non-IRC chatrooms >(e.g. we are switching to XMPP, not sure what else is around) > > C. One-to-one chat that is compatible with currently widespread practice > >I think that means XMPP + OTR, nowadays. > > D. One-to-one chat that protects metadata end-to-end >(that is: "who is chatting with whom") > >This suggests Ricochet or similar. > > E. Public chatroom for Tails user support > > Currently, Pidgin addresses B + C, and not D. In theory it also > addresses A + E, except that connecting to e.g. OFTC directly is not > reliable, so a more geeky setup is needed in practice. Good point! Still, I'm afraid of mixing up here stuff that Pidgin is doing already or is intended to do (A, B, C, and E) and stuff that Pidgin was never meant to do (D) if we're talking here about "simplify the problem of replacing Pidgin". I could think of other instant messaging use cases or properties that are still not in your list (private group chat, search and archive past public communications, offline-friendlyness, etc.) For more a nice list of properties people are playing with, check https://dymaxion.org/essays/pleasestop.html. Whether or not you like the message and the style, the list of properties is interesting. > I don't know of any tool that provides D _and_ another one among A, > B and C. So for the moment, I think that D should be solved separately. Exactly. ___ 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.
