Bug#913645: Oldstable also affected
Dear Maintainer, since upstream was able to reproduce the problem and locate the commits that cause it I did no further tests. It seems like they will undo two commits in order to solve the problem, hopefully not too many people get bit by this. Cheers, Bastian On 12/3/18 12:58 PM, Bastian Neuburger wrote: Hi Carsten, I forgot to report back, but I also created Upstream bug 1510212 (https://bugzilla.mozilla.org/show_bug.cgi?id=1510212). As I stated there it might take a while until I can test migration again, since I reinstalled my test machine with Buster and thus have no test environment with Jessie or Stretch right now. I'll report back to upstream how this goes.
Bug#913645: Oldstable also affected
Hi Carsten, I forgot to report back, but I also created Upstream bug 1510212 (https://bugzilla.mozilla.org/show_bug.cgi?id=1510212). As I stated there it might take a while until I can test migration again, since I reinstalled my test machine with Buster and thus have no test environment with Jessie or Stretch right now. I'll report back to upstream how this goes. Cheers, Bastian On 11/30/18 6:50 AM, Carsten Schoenert wrote: Control: forwarded -1 https://bugzilla.mozilla.org/show_bug.cgi?id=1505038 Hello Bastian, Am 20.11.18 um 17:44 schrieb Bastian Neuburger: Hi, I have however not yet tested what happens if you start thunderbird aftter the upgrade and close it right away (i.e. not trying to sign anything but also not entering the master password). I will try to test this later but now I need a working mail client. I also tested this variant now: 1. Have berkeley DB based profile that works fine with thunderbird 52 in Jessie 2. Upgrade thunderbird 3. Start thunderbird 4. Close it without doing anything (I am not prompted for the master password) 5. Start thunderbird again Expected results: Either key3.db is still there or I am getting prompted for a master password during step 4. Actual results: Everything under "Your certificates" and "People" in the Certificate Manager gone, all saved passwords gone. So the problem we encountered did not only wipe private keys, but also certificates of other people I already corresponded with AND stored passwords. How should reporting with upstream be handled? Should I take care of it myself or would you like to forward it? I haven't forwarded that all into a new upstream bug report, but I was able to talk about that issue with upstream. Initially upstream (in that case the NSS/Firefox team) has decided about 6 years ago to stop using the old database option [1] and use the newer NSS implementations for storing stuff within a database. Your are not the only person who is experience such problems. There is the report 1505038 [2] which is from a user with the same problems. The issue has some workaround mentioned in comment #25 which should be "solve" your current problem, could you please test this suggestion? [1] https://bugzilla.mozilla.org/show_bug.cgi?id=783994 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1505038 -- Neuburger, Bastian Telefon: +49-6159-71 1740 Abteilung: IT-Security GSI Helmholtzzentrum für Schwerionenforschung GmbH Planckstraße 1, 64291 Darmstadt, Germany, www.gsi.de Commercial Register / Handelsregister: Amtsgericht Darmstadt, HRB 1528 Managing Directors / Geschäftsführung: Professor Dr. Paolo Giubellino, Ursula Weyrich, Jörg Blaurock Chairman of the Supervisory Board / Vorsitzender des GSI-Aufsichtsrats: State Secretary / Staatssekretär Dr. Georg Schütte
Bug#913645: Oldstable also affected
Hi, I have however not yet tested what happens if you start thunderbird aftter the upgrade and close it right away (i.e. not trying to sign anything but also not entering the master password). I will try to test this later but now I need a working mail client. I also tested this variant now: 1. Have berkeley DB based profile that works fine with thunderbird 52 in Jessie 2. Upgrade thunderbird 3. Start thunderbird 4. Close it without doing anything (I am not prompted for the master password) 5. Start thunderbird again Expected results: Either key3.db is still there or I am getting prompted for a master password during step 4. Actual results: Everything under "Your certificates" and "People" in the Certificate Manager gone, all saved passwords gone. So the problem we encountered did not only wipe private keys, but also certificates of other people I already corresponded with AND stored passwords. How should reporting with upstream be handled? Should I take care of it myself or would you like to forward it? Kind regards, Bastian
Bug#913645: Oldstable also affected
Hi, > this is not differing between the Debian releases(, unfortunately). > Debian hasn't touched any code here. > ... > First we/you need to check please if this behavior is also existing in > the upstream binaries. To check this you can simply download the > pre-compiled binary and start the thunderbird binary from that archive. > > amd64 > http://ftp.mozilla.org/pub/thunderbird/releases/60.3.0/linux-x86_64/ > > i386 > http://ftp.mozilla.org/pub/thunderbird/releases/60.3.0/linux-i686/ > > If the issue is also existing here then this needs to be reported to the > Mozilla bugtracker and this report needs to be tagged to follow that report. > > https://bugzilla.mozilla.org/ Indeed this seems to be an upstream bug, the upstream release is also affected. I also tested some more and found out, that there is a way to avoid private key loss. The scenario that hit us was trying to sign a message after upgrade and when this failed thunderbird was restarted. The certificate was gone. But when I view an encrypted message before restarting thunderbird will prompt me for the master password and everything works fine. After entering it also signing works. While watching the nssPrivate table in key4.db I noticed that entering the master password will create a new entry in that table. After a restart, everything is still there and working. This also works when e.g. changing a server password and saving it to the password store, it seems the crucial factor is getting prompted for the master password and entering it correctly. I have however not yet tested what happens if you start thunderbird aftter the upgrade and close it right away (i.e. not trying to sign anything but also not entering the master password). I will try to test this later but now I need a working mail client. I am wondering why thunderbird will not prompt for the master password when first trying to sign a message, but only for decryption. I'll report back, Bastian
Bug#913645: Oldstable also affected
severity: critical Dear Maintainer, since I had an oldstable system with a key3.db around I also checked the behaviour there. I upgraded from thunderbird:amd64 (52.9.1-1~deb8u1, 60.3.0-1~deb8u1) and encountered the same situation: I couldn't decrypt messages anymore. Before trying to decrypt an encrypted message, my certificate was still visible in the "Your certificates" tab, after failing to display/decrypt an encrypted message it is no longer visible. I checked key4.db before this and I got the following output: Enter ".help" for usage hints. sqlite> .tables nssPrivate sqlite> select * from nssPrivate; sqlite> Also think the severity of this bug is critical since it causes severe data loss (private key gone: encrypted data gone). Please let me know if you have further questions. Kind regards, Bastian
Bug#913645: Upgrade to thunderbird 1:60.3.0-1~deb9u1 will purge user private keys if they are not stored in sqlite
Package: thunderbird Version: 1:60.3.0-1~deb9u1 Two coworkers experienced the following problem on Debian Stretch after upgrading from 1:60.2.1-2~deb9u1 to 1:60.3.0-1~deb9u1: After upgrading they no longer had their X509 certificate for signing and encryption listed in the "Your certificates" tab. Running sqlite on their profiles' key4.db made it apparent that the nssPrivate table contained no entries whatsoever. Also key3.db contained no entries wrt to certificates and/or private keys. I then restored a backup of their profiles from last week (before the upgrade) and I saw that this snapshot didn't contain the new sqlite versions of cert9.db and key4.db but only the Berkeley DB variants cert8.db and key3.db. Running strings on the restored key3.db I was able to see the CA that issued the certificate and the DN. After starting thunderbird 1:60.3.0-1~deb9u1 with the restored profile key4.db was created again - and again empty - and the entry in key3.db vanished. After restoring the profile once more and starting it with thunderbird 1:60.2.1-2~deb9u1 the certificate was listed in the "Your certificates" tab and after unlocking it with the master password they could send signed e-mails again. Another upgrade to 1:60.3.0-1 wiped the private key again. I suppose something goes horribly wrong when thunderbird tries to convert from Berkeley DB to sqlite. For other users (including myself) who already had a key4.db in place this issue does not occur. Even though the original thunderbird profiles were created probably on a Debian Wheezy icedove back in the day, I think this is a serious bug since it wipes private keys. If you need any further information please let me know. Kind regards, Bastian
Bug#791578: shorewall6: Broken Vcs-Git URL
Source: shorewall6 Severity: minor DUCK reported a problem with the Vcs-Git URL set in the source packages control file (c.f. http://duck.debian.net/sp/s/shorewall6.html). Currently it points to git://shorewall.git.sourceforge.net/gitroot/shorewall/shorewall/debian However it seems that this repository is not available anymore and it should probably now point to git://git.code.sf.net/p/shorewall/debian (not sure if the shorewall6/master branch in that repository is the correct one). Cheers, Bastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#790947: golang-xmpp-dev: Wrong homepage in control file
Source: golang-xmpp-dev Severity: minor DUCK reported a problem with the homepage set in the source packages control file. Currently it points to https://www.github.com/agl/xmpp However it seems that this code was moved to https://www.github.com/agl/xmpp-client as noted in [1], thus the homepage field should probably be updated to the new URL as probably also the debian/rules file to enable future builds. Cheers, Bastian [1] https://github.com/agl/xmpp-client/commit/bd4c83f9b8259d357fb1613da5b93f50d8aa8576 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#790948: gnome-doc-utils: Wrong homepage in control file
Source: gnome-doc-utils Severity: minor DUCK reported a problem with the homepage set in the source packages control file. Currently it points to https://live.gnome.org/GnomeDocUtils however it seems that live.gnome.org was discontinued. The new homepage for the Gnome Doc Utils should probably be https://wiki.gnome.org/Projects/GnomeDocUtils Cheers, Bastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#790950: gnome-video-effects: Wrong homepage in control file
Source: gnome-video-effects Severity: minor DUCK reported a problem with the homepage set in the source packages control file. Currently it points to https://wiki.gnome.org/GnomeVideoEffects however it seems to have moved to https://wiki.gnome.org/Projects/GnomeVideoEffects Cheers, Bastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#701629: ruby-json: After upgrade ruby-json from 1.7.3-2 to 1.7.3-3 chef-client stops working
Hi, I experienced the same thing. When first registering the client/node at the chef-server chef-client runs fine, but each chef run afterwards, it fails. The reason is that the data structure sent by the chef-server to the node was parsed as an object of class Chef::Node with ruby-json 1.7.3-2 and with 1.7.3-3 it is recognized as a hash instead of Chef::Node. Therefore the NoMethodError is thrown, since the chef sources only implement a function reset_defaults_and_overrides for the Node class, not for the Hash class. After downgrading the ruby-json package to 1.7.3-2 works, chef-client works again. I'm not sure if this bug report should also be filed against the chef package with a higher severity, but since the Debian Ruby Extras Maintainer take care of both packages, maybe they can decide. Cheers, Bastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#701629: Possible workaround
Hi, by replacing the file /usr/lib/ruby/vendor_ruby/chef/json_compat.rb, which is part of the chef package, with the one at https://github.com/opscode/chef/blob/834d814400a8a23ee8d865fa9d48e3f71895cd42/chef/lib/chef/json_compat.rb I could get chef-client to work with the ruby-json 1.7.3-3. However I am not sure if this has negative side effects in some scenarios. It seems that they switched JSON parsers from ::JSON.parse to ::Yajl::Parser.parse. Cheers, Bastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#697685: fix_paths patch does not fix ksh path
Package: environment-modules
Version: 3.2.9c-3
Tags: patch
Dear maintainer,
in the current version of the Debian package for environment module, the
init functions for ksh the variable MODULESHOME is set to
/usr/Modules/3.2.9, but it should point to /usr/share/modules.
For bash, zsh etc. you fixed this in fix_paths.patch, but for ksh this
is missing. The attached patch should fix the problem.
From: Bastian Neuburger b.neubur...@gsi.de
Date: Tue, 8 Jan 2013 14:36:21 +0100
Subject: fix_ksh_path
---
init/ksh.in |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/init/ksh.in b/init/ksh.in
index e545b2a..fbccdf1 100644
--- a/init/ksh.in
+++ b/init/ksh.in
@@ -7,10 +7,10 @@
@VERSIONING@fi
@VERSIONING@export MODULE_VERSION_STACK
-@VERSIONING@module() { eval
`@BASEPREFIX@/Modules/$MODULE_VERSION/bin/modulecmd ksh $*`; }
-@NOTVERSIONING@module() { eval `@bindir@/modulecmd ksh $*`; }
+@VERSIONING@module() { eval `/usr/bin/modulecmd ksh $*`; }
+@NOTVERSIONING@module() { eval `/usr/bin/modulecmd ksh $*`; }
-MODULESHOME=@prefix@
+MODULESHOME=/usr/share/modules
export MODULESHOME
if [ ${LOADEDMODULES:-} = ]; then
Cheers,
Bastian Neuburger
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#697349: Legacy setting in /etc/chef/solr.rb
Package: chef-solr Version: 10.12.0+dfsg-1 Severity: minor Dear maintainer, after installing chef-expander from package on Wheezy and starting it, I get the following warning: [Fri, 04 Jan 2013 10:51:20 +0100] WARN: You seem to have a legacy setting for solr_url: did you mean http://localhost:8983/solr ? The only file in /etc/chef that specifies solr_url is /etc/chef/solr.rb. The version of this file (chef-solr-10.12.0+dfsg/debian/etc/chef/solr.rb) shipped with the package contains the following line: solr_urlhttp://localhost:8983; After chaning that line, the warning disappears. The default line works however, it just throws a warning, but maybe it should be fixed anyhow. I am also not sure if this bug would be better off at the chef-expander package, but since that one doesn't ship a config file in /etc/chef I thought I'd report it here. Cheers, Bastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#697349: Legacy setting in /etc/chef/solr.rb
Hi, I forgot to mention that I changed that line to the one that was recommended in the warning message, so now it says: solr_urlhttp://localhost:8983/solr; Cheers, Bastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#684374: chef-solr: Broken symlinks prevent Solr from starting properly.
Hi, I can confirm the problems described. The symlink allows solr to start. However there seem to be some more problems regarding indexing. I will try to figure out what is wrong and create a separate bug report. Cheers, Bastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682067: gitrepo as FAI_CONFIG_SRC fails with fatal: Not a git repository /var/lib/fai/config/.git
Hi Andreas, the difference between running git clone --branch master git://gitserver/fai.git /var/lib/fai/config from a normal shell and the script included with FAI is that this script uses 2 git related environment variables: export GIT_WORK_TREE=$FAI export GIT_DIR=$FAI/.git So to reproduce the error in a shell, set $FAI to some directory and then copy/paste the two export statements before cloning. Then run git clone --branch master git://gitserver/fai.git $FAI So imo when setting the git environment variables, you would need to use git clone --branch master git://gitserver/fai.git $GIT_DIR instead. Cheers, Bastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682067: gitrepo as FAI_CONFIG_SRC fails with fatal: Not a git repository /var/lib/fai/config/.git
Hi, On Donnerstag, 19. Juli 2012, Bastian Neuburger wrote: When I use a git repository as config source for a FAI network install, FAI exits after trying to setup the config space from git. Inside /var/lib/fai there were not only the files I checked into the git repo but also the git control files (e.g. HEAD, refs/). Those should not be in /var/lib/fai but in /var/lib/fai/.git/ yes, they should. Seems your git repo is configured wrongly. (=as a bare git repo.) Maybe I am missing something here, but could you please elaborate on why the git internal files (HEAD, refs/, etc.) should be in /var/lib/fai and not inside a .git subdir within that directory? Especially the hooks directory is interesting here, since it exists within .git and in the FAI config space, so with the git control files and the config space in the same directory, this could cause conflicts. IMO the clone command in get-config-dir-git should check out to $GIT_DIR, see the patch at https://github.com/bneuburg/fai/commit/1b567f8c6790176c142f8373446265fa9b4e 00cf no, that patch is broken+wrong, as it breaks my (and several others) fai+git usage. $GIT_DIR is defined as $FAI/.git, and you really dont want your config space there, but in $FAI. I agree that the config space should not end up in $FAI/.git but $FAI. But with the patch I linked to the config space gets checked out to $FAI and HEAD, refs/ etc. end up in $FAI/.git, so the way I would expect it. Could you tell me how your git config space is set up? Cheers, Bastian -- Neuburger, Bastian Telefon: +49-6159-71 1740 Abteilung: IT-Security GSI Helmholtzzentrum für Schwerionenforschung GmbH Planckstraße 1 64291 Darmstadt www.gsi.de Gesellschaft mit beschränkter Haftung Sitz der Gesellschaft: Darmstadt Handelsregister: Amtsgericht Darmstadt, HRB 1528 Geschäftsführung: Professor Dr. Dr. h.c. mult. Horst Stöcker, Peter Hassenbach Vorsitzende des Aufsichtsrates: Dr. Beatrix Vierkorn-Rudolph Stellvertreter: Ministerialdirigent Dr. Rolf Bernhardt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682013: Confirmed: Second patch works
Hi, I finally got a working NFS-Root/initrd/Kernel with the second patch. Don't know where the problem was, might have to do with outdated packages (e.g. 3.2.0-2 Kernel instead of the current 3.2.0-3 Kernel) on my FAI-Server that I upgraded before trying again. Just wanted to let you know. It works fine for me even on KVM VMs. Cheers, Bastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682067: gitrepo as FAI_CONFIG_SRC fails with fatal: Not a git repository /var/lib/fai/config/.git
Package: fai-client Version: 4.0.3 Tags: patch When I use a git repository as config source for a FAI network install, FAI exits after trying to setup the config space from git. Inside /var/lib/fai there were not only the files I checked into the git repo but also the git control files (e.g. HEAD, refs/). Those should not be in /var/lib/fai but in /var/lib/fai/.git/ IMO the clone command in get-config-dir-git should check out to $GIT_DIR, see the patch at https://github.com/bneuburg/fai/commit/1b567f8c6790176c142f8373446265fa9b4e00cf After fixing it, installation is successful. Regards, Bastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682013: Confirmed, maybe a regression in dracut v0.20 vs v.019
Confirmed. I have a wheezy amd63 VM on which I successfully created a nfsroot with the example config just 10 days ago. With the resulting nfsroot, kernel and initrd I could successfully install clients. Now when repeating the same steps (i.e. running fai-setup with the example config) on a fresh virtual machine there are errors during fai-setup like described above. I also experience other errors when running fai-setup: Setting up dracut (020-1) ... dracut: Generating /boot/initrd.img-3.2.0-3-amd64 E: No '/dev/log' or 'logger' included for syslog logging Error: missing module or filename. chrooting to the nfsroot and running $ dracut --libdirs=/lib /usr/lib /home/initrd.img 3.2.0-3-amd64 results in E: No '/dev/log' or 'logger' included for syslog logging ... I: *** Installing kernel module dependencies and firmware *** Error: missing module or filename. ... When trying to pxeboot with the resulting kernels, dracut tells me that it does not support nfs, One of the differences I observed is that dracut in testing is at v0.20 since a week or so, and before it was v0.19 (this is the one in my working nfsroot). Also running dracut as described above in the same nfsroot with dracut 0.19 does not output errors, neither the E: No '/dev/log'.. nor the one about missing module or filename. Maybe we should file a bug against dracut 0.20 instead? Moreover the default package list in /etc/fai/NFSROOT seems to be have some conflict (but it already did on the working nfsroot, so I don't know if it could be the reason for the errors): install_packages: executing chroot /srv/fai/nfstest aptitude -R -y -o Dpkg::Options::=--force-conf def -o Dpkg::Options::=--force-confnew install nfs-common fai-nfsroot module-init-tools ssh rdate lshw rpcbind rsync lftp less dump reiserfsprogs e2fsprogs usbutils hwinfo psmisc pciutils hdparm s martmontools parted lvm2 dnsutils ntpdate dosfstools xfsprogs xfsdump procinfo numactl dialog kbd console-tools console-common iproute udev subversion xz-utils cupt dracut-network live-boot- live- boot-initramfs-tools- grub linux-image-2.6-amd64 ... The following packages have unmet dependencies: kbd : Conflicts: console-utilities which is a virtual package. console-tools : Conflicts: console-utilities which is a virtual package. The following actions will resolve these dependencies: Keep the following packages at their current version: 1) console-tools [Not Installed] One short time workaround, until the underlying problem is fixed, to setup a working fai nfsroot is to bootstrap/install the nfsroot with a repository from snapshot.debian.org before dracut 0.20 was introduced. You can do this by editing /etc/fai/apt/sources.list and the mirror url in /etc/fai/nfsroot.conf. Cheers, Bastian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
