Bug#1042460: openssh-client: ssh-agent CVE-2023-38408
Package: openssh-client Version: 1:8.4p1-5+deb11u1 Severity: grave Tags: security upstream Justification: user security hole X-Debbugs-Cc: mnalis-debian...@voyager.hr, Debian Security Team "The PKCS#11 feature in ssh-agent in OpenSSH before 9.3p2 has an insufficiently trustworthy search path, leading to remote code execution if an agent is forwarded to an attacker-controlled system." While it does not affect all users of ssh-agent, it does affect many of them and commonly suggested workaround (using jumphosts instead of agent forwarding) is not applicable to many use cases (git push over ssh, using libpam-ssh-agent-auth, etc.) https://security-tracker.debian.org/tracker/CVE-2023-38408 indicates that the new fixed version 1:9.3p2-1 has been uploaded in sid and trixie, however bookworm (stable) and bullseye (oldstable) still have no security fix since CVE release on 2023-07-20. (workaround by pinning fixed version from trixie is not possible, due to significant libraries clash; and there are no Debian backports either) -- System Information: Debian Release: 11.7 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-23-amd64 (SMP w/1 CPU thread) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages openssh-client depends on: ii adduser 3.118 ii dpkg 1.20.12 ii libc6 2.31-13+deb11u6 ii libedit2 3.1-20210910-1 ii libfido2-11.6.0-2 ii libgssapi-krb5-2 1.18.3-6+deb11u3 ii libselinux1 3.1-3 ii libssl1.1 1.1.1n-0+deb11u5 ii passwd1:4.8.1-1 ii zlib1g1:1.2.11.dfsg-2+deb11u2 Versions of packages openssh-client recommends: pn xauth Versions of packages openssh-client suggests: pn keychain pn libpam-ssh pn monkeysphere pn ssh-askpass -- no debconf information
Bug#999131: uqm-russian: provide fix by using dh sequencer
Package: uqm-russian Version: 1.0.2-5 Followup-For: Bug #999131 X-Debbugs-Cc: mnalis-debian...@voyager.hr Control: tags -1 patch Here is a MR to fix this, by using dh sequencer: https://salsa.debian.org/games-team/uqm-russian/-/merge_requests/1
Bug#999132: uqm: patch to use "dh"
Package: uqm Version: 0.6.2.dfsg-9.5 Followup-For: Bug #999132 X-Debbugs-Cc: mnalis-debian...@voyager.hr Control: tags -1 patch I've provided a patch to fix this by using dh sequencer. https://salsa.debian.org/games-team/uqm/-/merge_requests/1
Bug#999132: is help needed?
Is help needed in converting debian/rules to use dh? I certainly wouldn't want uqm to fall out of Debian. -- Opinions above are GNU-copylefted.
Bug#985825: do not remove useful packages due to political issues, please
Whatever you decide, please, do not consider *removing* useful package, just due to name controversy. That is not a good path to go down, IMHO. After all, we still have several "reiserfs" named packages in Debian main, and one should well argue that Hans Reiser actions were much bigger atrocity than RMS-based one. Perhaps check-dfsg-status might be good binary name (akin to check-support-status from debian-security-support package) if you are looking for non-controversial and easier to understand name. Please do contact release team ASAP to check about what renaming possibilities are available, and in what timeframes.
Bug#516394: removal of djbdns ?
Hi, I see djbdns is removed from testing, due to unarchiving of critical bug #516394 However, as source package djbdns 1:1.05-11 builds several binary packages (axfrdns, djbdns-conf, djbdns-utils, rbldns, tinydns, walldns) and the bug is only in (if not patched) dnscache, would other packages reenter testing and later new stable Debian? I don't particularly care about dnscache, but use other parts of djbdns (tinydns, axfrdns, djbdns-utils...) often. I don't know if only some binary packages sharing same source package can be blocked from entering testing, or how this should reasonably be handled so other binary packages remain in Debian (lowering severity to important, as much of the binaries are non-affected? patching dnscache with provided patches?) I am not DD/DM, but have some experience with creating Debian packages, so am willing to help if needed. Thanks! -- Opinions above are GNU-copylefted.
Bug#662960: ssmtp doesn't validate server TLS certificates
severity 662960 wishlist thanks The bug have been added tag "security", which is in sync with its TLS deficiencies. However (as you noticed) "Severity" values (while they might look innocently like plain English) have quite specific meanings in BTS, which sometimes might be at odds with their common language usages. Because of that "Severity" is not just a number from 0-5 indicating how much one would like for bug to be fixed, but something else. "Severity: important" would indicate that package is just one small step away from "rendering it completely unusable to everyone", which looks too harsh to me in this case (as in many cases ssmtp is used only for non-TLS plaintext SMTP delivery on LAN from satellite machines to main MTA, which would then speak TLS to outside world etc.) "Severity: wishlist" however (as opposed to "normal") subtly indicates that there is some functionality that is *missing*, and that someone needs to think it over and write it, and that it might be a more complicated task and probably not an one-line-fix (and thus it would probably left to upstream to fix it, as Debian maintainer in most cases won't be fixing it h[im/er]self unless upstream is dead and someone else provides a verified good patch). It also indicates it might be due to design decisions, like here. I do agree completely with you that package should strongly indicate in its docs and description about it's TLS deficiencies. If someone would write such a documentation patch, perhaps it might have a chance to be included. [ As a side note, even with certificate checking in place there are a lot of problems in todays "zillion untrusted CAs which we trust anyway" security model, and even more so if you move from web world (where clients try to be secure, and even people might sometimes check basic credentials) to unattended MTA world where almost nobody does, and vast majority of MTAs will simply by default silently downgrade to plaintext if they think anything might be problematic with TLS support etc. ] -- Opinions above are GNU-copylefted.
Bug#662960: ssmtp doesn't validate server TLS certificates
Hi Celejar, you have raised severity to "serious" on ssmtp Debian package in bug #662960, which is reserved for "Serious policy violations" as described at https://www.debian.org/Bugs/Developer#severities It is customary to indicate exactly which section of Debian policy Manual (at https://www.debian.org/doc/debian-policy/) the bug breaks when setting "serious" severity. While I do agree that limitations of TLS implementation should be prominently noted in package documentation and even description, I do not think that even completely non-existent TLS support qualifies for more than "important" severity (and more likely "normal" or "wishlist"). Unless someone objects with specific Debian policy section that this package runs afoul, I'm going to revert its severity back to wishlist. -- Opinions above are GNU-copylefted.
Bug#906847: workaround?
is workaround possible? (eg. having the Adblock plus be available for all users on system) I see in #906837 that for (similar) xul-ext-ublock-origin that the issue was fixed in unstable; could it also be fixed for xul-ext-adblock-plus? -- Opinions above are GNU-copylefted.
Bug#888484: Updates for stretch/jessie not in security repo
nor does debian security tracker list the updates as available for jessie/stretch: https://security-tracker.debian.org/tracker/source-package/clamav (security-tracked does say in hover text that jessie "gets updated via -updates", so it should pick that up) it correctly reports wheezy, buster and sid as fixed. for example, see also https://security-tracker.debian.org/tracker/CVE-2017-12376 this looks to me also like something that should be fixed (somewhere)?
Bug#796118: Re: Should djbdns be removed?
On Tue, Feb 09, 2016 at 06:00:40PM -0500, Robert Edmonds wrote: > Matija Nalis wrote: > > dnscache component only is RC-buggy. The solution has been proposed > > by Robert Edmonds (remove only buggy component /usr/bin/dnscache). > > > > It is not upstream orphaned. > > As far as I can tell, the only maintenance activity that djbdns has > received from its upstream developer has been the release of a two-line > patch, about 7 years ago: > > http://marc.info/?l=djbdns=123613000920446=2 I would consider a fact that software did not have serious security bug nor other compelling need to change for 7 years a big *plus* for using it, not as a problem. (But then again, I'm one of those guys running stuff on Debian Stable or even oldstable LTS) > The only upstream maintenance attention djbdns has received in the past > 15 years has been related to the security guarantee, and that security > guarantee is very narrowly tailored to problems that DJB finds > worthwhile; attacks enabled by the ease of forging UDP packets on the > Internet, or denial-of-service attacks are both specifically excluded > classes of problems. While I'd love to engage to in comparative analyses of various DNS software, or discuss how for example any DNS software supporting DNSSEC is by far a biggest denial-of-service amplifier attack, how BIND and other DNS tools were not even considered for removal even after having way bigger problems with forged UDP packets (for example, see https://cr.yp.to/talks/2012.03.08-1/slides.pdf) or note that other DNS software does not offer *any* gurantees at all, I do not feel that this bug report is a right place for it. > Other routine maintenance such as updating the list of root nameserver > address hints has simply been neglected. E.g., the dnsroots.global file One might say that editing a default list of servers is in domain of responsibility of sysadmin, not programmer (hey, I still remember days of AlterNIC and not using default InterNIC root server list). Still, I did offer to fix that trivial bug. > > It is just stable piece of software which does not change often, as it > > was engineered on KISS principle, so it does not *need* to be changed. > > That is great engineering feat, and I'd love if way more software > > would be like that instead of having everincreasing featurecreep. > > Many djbdns users speak about how well engineered or elegant the servers > are, but I suspect this comes from the experience of configuring the > daemons (which have very few configuration knobs compared to other DNS > implementations), rather than reading the code. Here are comments from > a security researcher with extensive experience analyzing source code: What does anecdotal rants with beauty of the code have to do with this bug? While I have not editied djbdns source (didn't have the need!) I did modify DJB's qmail and ucspi-tcp code written in similar style at times past, and had much less difficulty than average (see http://linux.voyager.hr/ for patches). But yes, the admin part is where tinydns and friends just shines. Does the job fast, efficient, with minimum administrative overhead, not getting in the way, providing the extremly easy way to integrate into it's surroundings. And no uneeded updates breaking stuff. Excellent security record for all tools but dnscache (and even there, it was first with improved protections > > I do not know why you think it *has* to be heavily patched. > > It works for me without patching just fine, for example. > > Many users have requirements that are not satisfied by the original > djbdns-1.05 source release. For example, the following post from a > Facebook developer mentions that tinydns is used at Facebook, with > multiple patches, including an in-house IPv6 support patch: > > > https://lists.dns-oarc.net/pipermail/dns-operations/2016-February/014250.html well, yes, adding support for whole new core layer3 technology does usually require some work. Upstream didn't do it as he doesn't belive it was the right way to do thinks (http://cr.yp.to/djbdns/ipv6mess.html). Some might agree that it could've been done way better. Too late for that now, IPv6 is here to stay. > > The recent DNS standards (DNSSEC, I assume) it doesn't support is by > > design, as it is deemed broken by upstream author (see > > http://dnscurve.org/ for more details, for example) and the whole > > point of KISS principle is to keep it simple and use modular design > > for extra bloat if wanted (for example, even DJB's dnscurve is to be > > implemented as separate independent software part, and not patching > > tinydns with its functionality) > > Can you cite any evidence that djbdns has a modular design, or that > enhancements can be implemented modularly, wi
Bug#796118: Re: Should djbdns be removed?
On Tue, Oct 06, 2015 at 04:26:49PM +0200, Ondřej Surý wrote: > > On Tue, Sep 08, 2015 at 08:29:18PM +0200, Moritz Mühlenhoff wrote: > > > On Wed, Aug 19, 2015 at 05:45:30PM +0200, Moritz Muehlenhoff wrote: > > > > djbdns is RC-buggy for many years now and was out of testing since 2009. > > > > Should we remove it from unstable? > > > > No, I don't think so. > > Any solid arguments supporting your opinion? > > djbdns is RC buggy, upstream orphaned, outdated, has to be heavily > patched, doesn't support recent DNS standards and it still even carries > old J-ROOT IP address that was decommissioned a ***13*** years ago. dnscache component only is RC-buggy. The solution has been proposed by Robert Edmonds (remove only buggy component /usr/bin/dnscache). It is not upstream orphaned. It is just stable piece of software which does not change often, as it was engineered on KISS principle, so it does not *need* to be changed. That is great engineering feat, and I'd love if way more software would be like that instead of having everincreasing featurecreep. I do not know why you think it *has* to be heavily patched. It works for me without patching just fine, for example. The recent DNS standards (DNSSEC, I assume) it doesn't support is by design, as it is deemed broken by upstream author (see http://dnscurve.org/ for more details, for example) and the whole point of KISS principle is to keep it simple and use modular design for extra bloat if wanted (for example, even DJB's dnscurve is to be implemented as separate independent software part, and not patching tinydns with its functionality) J-ROOT should be trivial to patch, care to file a bug for that? > I myself started my DNS journey with djbdns years ago, and I always > loved the code-style. It's very well written, but the world has moved > on, and it's time to *let it go*. Just let it go and let it rest in > peace, Gerrit. Ondřej, I see that you advertise competing DNS product; but really, there are some people more happy with tinydns than with any other peace of DNS software out there. I'm not a DD, but I am willing to do the work if it will be accepted. For that, I propose to do the following: - fix J-ROOT - split djbdns source package into: - djbdns-dnscache (dnscache only), - djbdns-auth (authorative DNS servers, like tinydns, axfrdns, walldns), - djbdns-tools (all the command line tools) Are there other issues that need fixing in order for most of djbdns package (everything except dnscache) friends not be RC-buggy? only djbdns-dnscache can remain RC-buggy then (until patched by someone). Would that work for everyone? -- Opinions above are GNU-copylefted.
Bug#756895: works for me...
severity 756895 important thanks It works for me on mysql, just tried upgrading from 1.12+dfsg-2 to 1.13 using dbconfig... it asks for admin password, and finishes ok: creating database backup in /var/cache/dbconfig-common/backups/tt-rss_1.12+dfsg-2.mysql. applying upgrade sql for 1.12+dfsg-2 - 1.13. dbconfig-common: flushing administrative password Also, column width is only found in /usr/share/dbconfig-common/data/tt-rss/upgrade/mysql/1.13 (alter table ttrss_enclosures add column width integer not null default 0) so previous versions should not have that unless something else set it... If someone can find a way to reliably reproduce this problem, I'd help to track it down and patch it. (as it does not make the package completely unusable to everyone, I'm setting severity to important) -- Opinions above are GNU-copylefted. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696210: lower severity
severity 696210 important thanks As this does not rendering package completely unusable to everyone (especially regarding existing workarounds using different phonon backends), I'm lowering severity to important. You may want to reassign to other package or close if it can be shown it is/was because of gstreamer libraries... -- Opinions above are GNU-copylefted. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516394: A Backport please
On Thu, Feb 17, 2011 at 12:08:30PM +, Martin Nicholas wrote: Could someone _please_ generate a backport (or forwardport!) to squeeze? I'm sure I'm not the only person who has a requirement for tinydns. You can run package from sid or experimental on squeeze: http://packages.debian.org/search?keywords=dbndns http://packages.debian.org/search?keywords=djbdns (without backports, as libraries dependencies did not change yet) -- Opinions above are GNU-copylefted. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#549014: wmbubble fix for squeeze
tags 549014 patch thanks *** Please type your report below this line *** The bug in wmbubble 1.46-2 only seems to happen only with WindowMaker. I've tried with AfterStep, twm and xfce4 and there the applet normally shows picture. Looking into the code, it appears the fix just needs to be enabled for it to also work for WindowMaker. Attached is micro patch which does that. diff -ru wmbubble-1.46/Makefile wmbubble-1.46.fixed/Makefile --- wmbubble-1.46/Makefile 2010-10-15 19:57:42.0 +0200 +++ wmbubble-1.46.fixed/Makefile 2010-10-15 19:58:49.0 +0200 @@ -2,7 +2,7 @@ EXTRA = -DENABLE_DUCK EXTRA += -DENABLE_CPU EXTRA += -DENABLE_MEMSCREEN -# EXTRA += -DKDE_DOCKAPP +EXTRA += -DKDE_DOCKAPP EXTRA += -DUPSIDE_DOWN_DUCK # where to install this program
Bug#549014: wmbubble: patch to fix it
Package: wmbubble Version: 1.46-2 Severity: normal here is the patch -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (650, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=hr_HR, LC_CTYPE=hr_HR (charmap=ISO-8859-2) Shell: /bin/sh linked to /bin/dash Versions of packages wmbubble depends on: ii libatk1.0-0 1.30.0-1The ATK accessibility toolkit ii libc62.11.2-6Embedded GNU C Library: Shared lib ii libcairo21.8.10-6The Cairo 2D vector graphics libra ii libglib2.0-0 2.24.2-1The GLib library of C routines ii libgtk2.0-0 2.20.1-1+b1 The GTK+ graphical user interface ii libpango1.0-01.28.1-1Layout and rendering of internatio ii libx11-6 2:1.3.3-3 X11 client-side library wmbubble recommends no packages. Versions of packages wmbubble suggests: ii sox 14.3.1-1+b1 Swiss army knife of sound processi ii xfce4-terminal [x-terminal-e 0.4.5-1 Xfce terminal emulator ii xterm [x-terminal-emulator] 261-1 X terminal emulator -- no debconf information diff -ru wmbubble-1.46/Makefile wmbubble-1.46.fixed/Makefile --- wmbubble-1.46/Makefile 2010-10-15 19:57:42.0 +0200 +++ wmbubble-1.46.fixed/Makefile 2010-10-15 19:58:49.0 +0200 @@ -2,7 +2,7 @@ EXTRA = -DENABLE_DUCK EXTRA += -DENABLE_CPU EXTRA += -DENABLE_MEMSCREEN -# EXTRA += -DKDE_DOCKAPP +EXTRA += -DKDE_DOCKAPP EXTRA += -DUPSIDE_DOWN_DUCK # where to install this program
Bug#516394: so the solution ?
tags 516394 patch thanks Hi Gerrit, I'd appreciate very much if you could spare this update some time. Thanks. I see in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=516394#10 that you have a problem with http://www.your.org/dnscache/0001-dnscache-merge-similar-outgoing-queries.patch due to issues at http://thread.gmane.org/gmane.network.djbdns/13705/focus=13868 Are you aware of new (fixed) version of the patch at: http://marc.info/?l=djbdnsm=123859517723684w=1 It should fix mentioned concerns, and it also allows one to shut down the patch at runtime simply by not setting MERGEQUERIES environment variable (which should probably set by default to keep Security team happy). Now, I completely agree with you and DJB that the issue at hand is actually design error in DNS protocol itself, and that being able to poison in few minutes instead of in few hours is not really such a tremendous difference that djbdns should be excluded from Debian Stable, and BIND and all other DNS proxy servers shouldn't (which I wildly guess is the root of your conflict with security team). That said, while I agree with DJB that this is fundamental DNS design issue, I do not see Debian Security Team removing all DNS proxy related packages (nor would that accomplish anything security-wise), not do I see the DNS being redesigned from scratch and redeployed all over the world before new Debian Stable is out (not even if it took longer than Sarge!) While I completely agree with DJB that DNS is fundamentally broken, I just don't buy into such fatalist and nihilist approach as it's broken and we're all doomed. Now, if there is a ready, deployable right now and *interoperable right now* fix (which there isn't AFAIK), by all means let's use it; but until such a beast is available, we should strive to achieve BCP, even if it just adds some speed bumps. Otherwise, the evolution (or at least the Debian Security Team) will wipe out the weakest (being unpatched dnscache ATM, after all those years of it being the best). However, even without knowing about your discussions with security team (which seem to have gone sour, which make me sad), I might probably agree with them that solution of lowering MAXUDP to just 20 which you propose in: in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=516394#36 is not very good solution (even if not for their reasons!) - while it will happily work for SOHO, it would make a package hardly usable on most sites much bigger than that. (I've run dnscache on mid-sized sites to low-end ISP (about 20k users), and more than once did I have to raise the limit from 200 upwards). But I can also see why you wouldn't like to poison the dnscache code with mostly untested in the wild patches (especially given whole djbdns/dbndns distinction). However, I would very much like to know your stand on that, given the above (some of it new?) information. As I see, the possible options are (from worst to best IMHO): a) nothing is done - djbdns/dbndns drops from debian stable completely b) dnscache is removed from the package; this fixes this bug and allows at least other parts of the package to enter debian stable (tinydns, walldns, rbldns, utils, ...) c) new patch at http://marc.info/?l=djbdnsm=123859517723684w=1 is applied, with default MERGEQUERIES set in dnscache-run package. I assume that one would make security team happy, and since everyone can disable the patch if they don't trust it, it might make you happy enough to. You could even popup the dialog on upgrade to let the user know or even choose their options. Alternatively, Francis patch at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=516394#106 is shown good enough to fix the issue and we use that. Gerrit, I know you're probably frustrated with this issue, but I'd really appreciate your take on this. Is there anything the rest of community can do? Do you see any other options? I guess (a) will happen by default if nothing is done, and that seems like the worst option for the users of djbdns to me... -- Opinions above are GNU-copylefted. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#549014: wmbubble: What version of dependecies?
Package: wmbubble Version: 1.46-2 Severity: normal Hi Giovanni, what version of wmbubble dependecies do you have? (and especially libgtk2.0-0 version ?) -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686-bigmem (SMP w/2 CPU cores) Locale: LANG=hr_HR.ISO-8859-2, LC_CTYPE=hr_HR.ISO-8859-2 (charmap=ISO-8859-2) Shell: /bin/sh linked to /bin/dash Versions of packages wmbubble depends on: ii libatk1.0-0 1.30.0-1The ATK accessibility toolkit ii libc62.11.2-5Embedded GNU C Library: Shared lib ii libcairo21.8.10-5The Cairo 2D vector graphics libra ii libglib2.0-0 2.24.1-1The GLib library of C routines ii libgtk2.0-0 2.20.1-1+b1 The GTK+ graphical user interface ii libpango1.0-01.28.1-1Layout and rendering of internatio ii libx11-6 2:1.3.3-3 X11 client-side library wmbubble recommends no packages. Versions of packages wmbubble suggests: ii rxvt [x-terminal-emulator]1:2.6.4-14 VT102 terminal emulator for the X ii sox 14.3.1-1 Swiss army knife of sound processi ii xterm [x-terminal-emulator] 261-1 X terminal emulator -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516394: Is there a plan to get djbdns again into testing
On Fri, Feb 19, 2010 at 02:44:39PM -0600, Jamieson Becker wrote: On 02/19/2010 02:07 PM, L. Alberto Giménez wrote: Would they mind to propose a way to have djbdns back in testing? I think that there is a quite bunch of people using djbdns, and it would be very nice to have it packaged for Debian. +1 -- Opinions above are GNU-copylefted. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#403454: mindi does rm -Rf /home !
On Sat, Dec 23, 2006 at 09:55:29AM +1100, Andree Leidenfrost wrote: Would you be able to send your two patches to the BTS, one attached to #403454 and the second one attached to a new bug report for the LABEL issue? I think this way we'd minimise the risk of me getting it wrong. (I am a bit nervous because of the freeze as I have really only one shot to get it right.) Sure. Attached here is an oneliner fix for rm -Rf /home I've also reported the other one to BTS (no bug# yet, still waiting for it to process the message) But I'll be visiting LCA2007 in Sydney in mid-January, so direct interrogation is an option :) Hey, I'll be there as well, so it would be great to catch up! :-) However, I defintiely want to fix the issue at hand and the label issue as well as soon as possible. I know, I see the etch is frozen now. Both patches are trivial, so they shouldn't be a problem. -- Opinions above are GNU-copylefted.--- mindi/mindi (révision 919) +++ mindi/mindi (copie de travail) @@ -2985,7 +2985,7 @@ FindIsolinuxBinary FindLiloBinary fi -grep -F $TMP_ROOT /proc/mounts | grep -F tmpfs /dev/null 2 /dev/null TMP_ROOT=/home LogIt Changing TMP_ROOT to $TMP_ROOT because you're using tmpfs for /tmp\n ; # tmpfs doesn't like Mindi and /tmp, for some reason +grep -F $TMP_ROOT /proc/mounts | grep -F tmpfs /dev/null 2 /dev/null TMP_ROOT=/home/tmpmondo mkdir -p $TMP_ROOT LogIt Changing TMP_ROOT to $TMP_ROOT because you're using tmpfs for /tmp\n ; # tmpfs doesn't like Mindi and /tmp, for some reason rm -f /tmp/mindi_lo trap Aborted SIGTERM DONE=\r\t\t\t\t\t\t\t\tDone.
Bug#403454: mindi does rm -Rf /home !
On Thu, Dec 21, 2006 at 10:38:35PM +1100, Andree Leidenfrost wrote: Looking at the mailing list thread it looks like the patch listed in both the mailing list thread and in trac ticket 100 is the same and did not work because you wrote in the mailinglist thread in response to the patch: [...] Mondo doesn't run now, but at least it does not destroy the /home. Last version that I had used before, and which had created backups successfully was 2.06-4 (Andree's debian package, rebuilt for sarge) [...] No, that patch actually DID fix the rm -Rf /home problem correctly. It is just that I had _two_ major problems to start with: (1) the critical one in trac ticket 100 about rm -Rf /home, (I reported this one in Debian BTS as #403454) (2) the important bug about misdetection of LABEL= in /etc/fstab on debian because of hardcoded /bin/cut path (wrong path on debian) see http://sourceforge.net/mailarchive/message.php?msg_id=37518492 (I did not report this one on Debian BTS yet. Should I?) both have been fixed promptly in upstream. I might send you a patch to try against mindi-2.20-1. Would you be able to test it? I intend to get this fixed over the weekend, i.e. no later than 24 Dec 06. I can run tests (one run per day -- big server, takes a long time) and give feedback until 28 Dec; after that I'll be unavailable until end of January. FYI, the server currently runs your mindi 2.20-1 recompiled for sarge with only patches for above two problems, and it works ok. Andree Leidenfrost @ Debian Developer Sydney - Australia But I'll be visiting LCA2007 in Sydney in mid-January, so direct interrogation is an option :) -- Opinions above are GNU-copylefted. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403454: mindi does rm -Rf /home !
Package: mindi Version: 2.20-1 Severity: critical Sometimes mindi decides to set TMP_ROOT to /home (if /tmp is mounted as tmpfs), and then at the cleanup phase does rm -Rf $TMP_ROOT. In practice, this resulted in losing whole /home directory. thread describing the problem in detail can be found at http://sourceforge.net/mailarchive/message.php?msg_id=37329155 The bug has since been fixed upstream, see http://trac.mondorescue.org/ticket/100 -- Opinions above are GNU-copylefted. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
