Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 106497

Summary: app-backup/mondo-rescue removal request
Product: Gentoo Security Reporter: Romang <zataz>
Component: AuditingAssignee: Gentoo Security <security>
Status: RESOLVED FIXED    
Severity: enhancement CC: app-backup, bruno, chad.simmons, fryfrog, Henry78, jakub, jesse, liquidx, liv-public, mailingdotlist, mansourmoufid, pfeifer, portage, ti.liame, treecleaner, wayne, wschlich
Priority: High    
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---
Bug Depends on:    
Bug Blocks: 79262    

Description Romang 2005-09-19 03:23:05 UTC
#########################################################

mondo-rescue insecure temporary file creation

Vendor: http://www.mondorescue.org/
Advisory: http://www.zataz.net/adviso/mondo-rescue-09192005.txt
Vendor informed: yes
Exploit available: yes
Impact : low
Exploitation : low

#########################################################

The vulnerabilities are due to insecure temporary files creation.

They are symlink attacks to create arbitrary files with the privileges of the
user running the affected script.

##########
Versions:
##########

mondo-rescue <= 1.65

##########
Solution:
##########


#########
Timeline:
#########

Discovered : 2005-09-19
Vendor notified :
Vendor response :
Vendor fix :
Vendor Sec report (vendor-sec@lst.de) :
Disclosure :

#####################
Technical details :
#####################

Vulnerable code :
-----------------

Take a look on the installed script (Gentoo distro)

* /usr/share/mondo/restore-scripts/mondo/hack-lilo

4 LogIt() {
5     echo "$1" >> /tmp/mondo-restore.log
6 }

116 LogIt "hack-lilo --- starting"

142 LogIt "hack-lilo --- leaving"

This script is world executable


* A lot off unused script are installed into /usr/share/mondo/restore-scripts/mondo/

The LogIt function is not declared into this scripts.
All this scripts should be removed.


#########
Related :
#########

Bug report :
CVE :

#####################
Credits :
#####################

Eric Romang (eromang@zataz.net - ZATAZ Audit) - Gentoo Security Scout
Thxs to Gentoo Security Team.
Comment 1 Sune Kloppenborg Jeppesen gentoo-dev 2005-10-06 12:04:37 UTC
tigger/taviso/vapier/solar please advise. 
Comment 2 SpanKY gentoo-dev 2005-10-06 16:16:01 UTC
why dont we ask the maintainer :)
Comment 3 Sune Kloppenborg Jeppesen gentoo-dev 2005-10-13 22:34:17 UTC
Please advise. 
Comment 4 Sune Kloppenborg Jeppesen gentoo-dev 2005-11-11 00:56:14 UTC
CC'ing Wolfram instead of group which doesn't play well with restricted bugs. 
 
Please advise. 
Comment 5 Wolfram Schlich (RETIRED) gentoo-dev 2005-11-11 01:17:47 UTC
Well, since I had really bad experiences dealing with the Mondo developer
regarding some weird problems, I stopped using it, as well as caring for the
ebuilds.
Also the stuff hasn't been updated for a year now (except some CVS snapshots
from 05/2005) -- see http://www.mondorescue.org/download/MondoCD/TGZS/

anyway, as to the vulnerability, I guess we need to remove all Mondo 1.x
versions from the tree. also, those older versions aren't listed on the Mondo
website anymore and the SRC_URI in the 1.x ebuilds doesn't work either :(
Comment 6 Sune Kloppenborg Jeppesen gentoo-dev 2005-11-11 01:24:30 UTC
Thx for the info, Wolfram.  
 
If possible please CC another possible maintainer from app-backup herd. 
Comment 7 Wolfram Schlich (RETIRED) gentoo-dev 2005-11-11 01:40:09 UTC
metadata.xml lists Jay Pfeifer, CCing...
Jay, please have a look at this :-)
Comment 8 Jay Pfeifer (RETIRED) gentoo-dev 2005-11-19 13:04:35 UTC
i certainly did help with these a while back and have been named as a
maintainer. but just like Wolfram, upstream is not a lot of fun. I would be all
for removing 1.x and 2.x as I don't see it being easily supported in the future.
Plus they seem to be dead upstream. I get tired of the upstream using the same
file name for new revisions (ie. making several 2.1.0 versions and telling no one).
Comment 9 Wolfram Schlich (RETIRED) gentoo-dev 2005-11-19 13:46:08 UTC
I agree with Jay here -- let's have it removed (maybe until
upstream changes the behaviour).
Comment 10 Sune Kloppenborg Jeppesen gentoo-dev 2005-11-19 14:06:32 UTC
Package.mask notice sent to -core. 
Comment 11 Sune Kloppenborg Jeppesen gentoo-dev 2005-11-21 00:24:48 UTC
No new maintainer. Wolfram/Jay please mask. 
Comment 12 Wolfram Schlich (RETIRED) gentoo-dev 2005-11-26 01:59:06 UTC
When masking app-backup/mondo-rescue, does it make sense
to keep app-backup/mindi and app-backup/mindi-kernel?
I believe those are only used by mondo-rescue...
Comment 13 Wolfram Schlich (RETIRED) gentoo-dev 2005-11-26 02:24:19 UTC
app-backup/mondo-rescue masked.
Comment 14 Romang 2005-11-30 04:00:44 UTC
Hello,

Vendor notified and vendor-sec also.

Regards.
Comment 15 Sune Kloppenborg Jeppesen gentoo-dev 2005-12-14 04:20:43 UTC
Keeping this bug open until the package is completely removed. 
Comment 16 Sune Kloppenborg Jeppesen gentoo-dev 2006-03-21 11:46:13 UTC
Jay and Wolfram any reason to keep mondo-rescue any longer?
Comment 17 Sune Kloppenborg Jeppesen gentoo-dev 2006-04-07 23:16:15 UTC
Any news on this one?
Comment 18 Wolfram Schlich (RETIRED) gentoo-dev 2006-05-06 12:56:13 UTC
Ok, we have a reason to keep and unmask it:
Upstream has a new maintainer: Bruno Cornec.
He just sent me a mail stating he is willing to produce mondo and mindi packages for Gentoo and to care about all issues.
That sounds good to me, as there seems to be someone actually caring about the project.
Comments? 
Comment 19 Sune Kloppenborg Jeppesen gentoo-dev 2006-05-06 22:10:02 UTC
Wolfram if you want to maintain it or has found a maintainer for it. Feel free to unmask it once the outstanding issues are fixed.
Comment 20 solar (RETIRED) gentoo-dev 2006-05-28 07:05:44 UTC
This bug should not be restricted.
Comment 21 Lisa Seelye (RETIRED) gentoo-dev 2006-06-17 19:22:33 UTC
So with the new upstream developer how does this stand? I'm just coming into the app-backup herd and trying to sort some bugs (namely bug 79262).

http://www.zataz.net/adviso/mondo-rescue-09192005.txt is offline.

What exactly does this effect? mondo-rescue-1.47? (That is the only one <=1.6) 2.x series?
Comment 22 Bruno Cornec 2006-06-18 15:45:14 UTC
Hello,

I've produced 2.0.8-3 (upstream version recently).
I have a gento qemu VM running.
But I still had not enough time to play with it, understand how to test my preliminary e-build script, ...
Of course, now everything is under SVN, so if some of you are wanting to have a look, that would be great :-)
Anyway, I'm working on producing ebuilds asap, but I'm quite busy on various topics right now, so don't expect it for tomorrow :-(

Also, the security issues I've seen reported here, are not yet fixed. I'm interested to fix them, so again will do as time permits. Patches welcome ;-)

Thanks for you rpatience on this.
Bruno.
Comment 23 Bruno Cornec 2006-08-07 17:16:08 UTC
Hello,

I've just published a new version of mondo/mindi which fixes some bugs, and
could begin to provide solutions for gentoo issues reported here.

I've also tried to work on a ebuild version updated, which I attach here for
comment.

Let me know how to procede now.
Comment 24 Bruno Cornec 2006-08-09 04:53:01 UTC
This script is not world writable anymore in the latest 2.0.9 version.
Please refer to ftp://ftp.mondorescue.org/gentoo/1.6 for ebuild files and packges built with them which correct this bug.
Comment 25 Bruno Cornec 2006-11-10 23:41:01 UTC
This bug should now be closed and a new version of mondo and mindi should be
added from upstream (which I maintain) using the latest 2.2.0 (mondo) and 1.2.0
(mindi) available from ftp://ftp.mondorescue.org/gentoo/1.6 
I will shortly add the new required mindi-busybox package as well there.
Comment 26 Jakub Moc (RETIRED) gentoo-dev 2006-11-14 00:14:59 UTC
*** Bug 155092 has been marked as a duplicate of this bug. ***
Comment 27 Jeff Cranmer 2006-11-29 18:26:39 UTC
I haven't tried a restore yet, but I was able to successfully create a pair of backup DVDs with the latest version of mondo and mindi (2.2.0 and 1.2.0) on an amd64 dual-core system.

Ignore mindi-kernel, and use the command switch '-k /boot/kernel-2.6.17-gentoo-r8', replacing the kernel path with whatever kernel you're actually booting from.

I had to mess around a little with the ebuild files to get it to build (though only to correct a couple of minor differences between file naming conventions).  Looks like it is ready to add back into portage.

Jeff
Comment 28 Bruno Cornec 2007-01-04 04:22:49 UTC
A newer version (2.2.1) with ebuild packages is available at ftp://ftp.mondorescue.org/gentoo/1.6
Please provide feedback and info for return back in gentoo's tree.
Comment 29 Sune Kloppenborg Jeppesen gentoo-dev 2007-01-06 12:56:23 UTC
@Bruno, you might want to post to gentoo-dev to find a maintainer for this package. Unless one is found it will stay masked.
Comment 30 Bruno Cornec 2007-01-08 21:25:11 UTC
I thought that the package already had a maintainer. If it's not the case, I'll post to gentoo-dev. Thanks for the advise.
Comment 31 Sune Kloppenborg Jeppesen gentoo-dev 2007-01-09 08:28:52 UTC
According to metadata.xml pfeifer@gentoo.org is primary maintainer and wschlich@gentoo.org secondary. Both are CC'ed on this bug as is the app-backup herd, so let's see wether they respond. We need an active maintainer to unmask this one.
Comment 32 Aniruddha 2007-04-24 06:29:52 UTC
What's the status on mondo-rescue? Why is it still hard masked? Looks to me it's time to return it back in Gentoo's tree.Bruno has posted his version 4 months ago! 
Comment 33 Bruno Cornec 2007-04-24 07:14:09 UTC
It's seems the problem is that there is no maintainer anymore for it in gentoo.
I can publish myself ebuilds, if I can find someone to tst them and report. A new version is available since last friday, and has even some updates for the ebuild.
Let me know how to proceed.
Comment 34 Aniruddha 2007-04-24 08:23:52 UTC
(In reply to comment #33)
> It's seems the problem is that there is no maintainer anymore for it in gentoo.
> I can publish myself ebuilds, if I can find someone to tst them and report. A
> new version is available since last friday, and has even some updates for the
> ebuild.
> Let me know how to proceed.
> 

First off all thank you for your patience and persistence. I suspect the problem is lack of manpower on the Gentoo side. I think it is best to attach your ebuild to this bugreport so we can test the ebuild.
Comment 36 Aniruddha 2007-04-24 21:24:39 UTC
Thanks Bruno. I will test them asap.What do you think about posting a 'maintainer wanted' message to gentoo-dev list?
Comment 37 Sune Kloppenborg Jeppesen gentoo-dev 2007-04-30 09:27:12 UTC
Or you could file a new bug assigned to maintainer-wanted and reference this bug.
Comment 38 Bruno Cornec 2007-05-01 22:40:17 UTC
Is that what you meant:
http://bugs.gentoo.org/show_bug.cgi?id=176738
(I was unable to assign to maintainer-wanted, so I put them in Cc: Hope that's ok)
Comment 39 Aniruddha 2007-06-07 17:21:31 UTC
How are things going here? Have you found a maintainer?
Comment 40 Bruno Cornec 2007-06-07 20:46:36 UTC
Well on the mailing I have a gentoo tester of the x86_64 version who has some issues we're resolving right now.

As soon as it's OK, I think he will come back for a formal request.

I don't know what is the rule for gentoo my self, but I can provide updates of packages with upstream updates, I have the process in place to do that easily. Just let me know how to propagatethem then to gentoo upstream.

Best regards,
Bruno.
Comment 41 Aniruddha 2007-06-07 21:16:37 UTC
Good to hear thing are moving forward :). I don't know the answers to your question (I am not a Gentoo dev). Thanks for your input!
Comment 42 Talamona Francesco 2007-06-10 05:56:10 UTC
Hi people, it's me. We are testing mindi and mondo on 64 bit arch. I'd like to make our work public in order to find someone else help too.

Maybe mindi an mondo related bus are today a little messy and outdated. IMHO it's time to close all bugs depending on surpassed versions, leave one only report open to make public work progression.
Comment 43 Aniruddha 2007-11-29 19:17:23 UTC
When will this bug be solved? New mondo ebuild are available for a while now: ftp://ftp.mondorescue.org/gentoo
Comment 44 Jakub Moc (RETIRED) gentoo-dev 2008-02-03 03:09:30 UTC
# Wolfram Schlich <wschlich@gentoo.org> (26 Nov 2005)
# has security issues and will be removed from portage
# due to upstream behaviour, see bug #106497
app-backup/mondo-rescue

Enough is enough. Treecleaners, please remove this. Masked for over two years.
Comment 45 Bruno Cornec 2008-02-03 05:56:37 UTC
I think it would be interesting you wait a couple of days more as Wolfram accepted to work on this as mentioned in http://bugs.gentoo.org/show_bug.cgi?id=176738
Comment 46 Jakub Moc (RETIRED) gentoo-dev 2008-02-03 09:12:21 UTC
(In reply to comment #45)
> I think it would be interesting you wait a couple of days more as Wolfram
> accepted to work on this as mentioned in
> http://bugs.gentoo.org/show_bug.cgi?id=176738

I've seen this so many times with mondo-rescue that I don't take it very seriously, frankly. Unless it's in usable state by the end of February, it *really* should be just wiped, once and for all. The current ebuilds are useless bitrot.

Comment 47 Samuli Suominen gentoo-dev 2008-02-10 09:31:37 UTC
I'd like to point out that mondo-rescue completely fails with slang-2 which is the default slang in ~arch now, going stable in about 30 days
Comment 48 Bruno Cornec 2008-02-16 00:58:26 UTC
Could you elaborate more on what you mean by "completely fails" ?
Any log ?

As for "The current ebuilds are useless bitrot", I'd like to have more info on why and how to improve them from your point of view.
Comment 49 Wolfram Schlich (RETIRED) gentoo-dev 2008-02-26 10:31:13 UTC
I've been actively trying to get in touch with Bruno Cornec since
2008-02-18 to sort out some questions I have regarding the mondo/mindi
ebuilds he provided -- I need answers until I can add anything to Portage.
Unfortunately, this was unsuccessful so far, but I keep trying.
Just wanted to post a status update for Jakub who will probably remove the packages in 5 days.
Comment 50 Jakub Moc (RETIRED) gentoo-dev 2008-02-26 10:44:12 UTC
(In reply to comment #48)
> Could you elaborate more on what you mean by "completely fails" ?
> Any log ?

As in the tarballs for the current ebuilds *in* *the* *tree* are garbage that doesn't even unpack properly. Unusable.

(In reply to comment #49)

Well, I'm just pointing out that this thing has been dragging for quite some time, it's been masked for over two years... so it'd really be nice to resolve this fast and push something usable into the tree, or get rid of the package once and for all. 
Comment 51 Samuli Suominen gentoo-dev 2008-02-26 14:20:49 UTC
(In reply to comment #48)
> Could you elaborate more on what you mean by "completely fails" ?

Means it's not compatible with API/ABI provided by >=slang-2 and it fails to build 
due to invalid or missing code

> Any log ?

Had one, but didn't save it because this one is package.masked & getting removed..
Comment 52 Wolfram Schlich (RETIRED) gentoo-dev 2008-03-05 00:15:35 UTC
(In reply to comment #50)
> (In reply to comment #48)
> > Could you elaborate more on what you mean by "completely fails" ?
> > Any log ?
> 
> As in the tarballs for the current ebuilds *in* *the* *tree* are garbage that
> doesn't even unpack properly. Unusable.
> 
> (In reply to comment #49)
> 
> Well, I'm just pointing out that this thing has been dragging for quite some
> time, it's been masked for over two years... so it'd really be nice to resolve
> this fast and push something usable into the tree, or get rid of the package
> once and for all. 

So, I tried to contact Bruno more than once again.
Nothing more than a 'Yes' via Jabber tonight.
I'm not very happy with the situation.
If this keeps on going like this, I don't see a point in
proxy-maintaining stuff for someone how doesn't respond.
But I'd like to give it 2 more weeks.
Jakub, if nothing happens until 23rd of March, go on with the removal.
Thanks!
Comment 53 Robert Buchholz (RETIRED) gentoo-dev 2008-03-05 00:47:22 UTC
Can we last-rite this now already? This will give the non-responsive maintainer another four weeks to push an update, otherwise have it removed in april.
Comment 54 Bruno Cornec 2008-03-08 16:52:08 UTC
(In reply to comment #52)
> (In reply to comment #50)
> > (In reply to comment #48)
> > > Could you elaborate more on what you mean by "completely fails" ?
> > > Any log ?
> > 
> > As in the tarballs for the current ebuilds *in* *the* *tree* are garbage that
> > doesn't even unpack properly. Unusable.
> > 
> > (In reply to comment #49)
> > 
> > Well, I'm just pointing out that this thing has been dragging for quite some
> > time, it's been masked for over two years... so it'd really be nice to resolve
> > this fast and push something usable into the tree, or get rid of the package
> > once and for all. 
> 
> So, I tried to contact Bruno more than once again.
> Nothing more than a 'Yes' via Jabber tonight.
> I'm not very happy with the situation.
> If this keeps on going like this, I don't see a point in
> proxy-maintaining stuff for someone how doesn't respond.
> But I'd like to give it 2 more weeks.
> Jakub, if nothing happens until 23rd of March, go on with the removal.
> Thanks!
> 

Well I'm sorry, I'm not in front of my computer every minute to tal via jabber. I'm a mail person. And I copied my responses to your jabber questions via e-mail, hope you got them.

I'm also a bit concerned that people speak about "garbage", "completely fails". Hey guys, this is a science here. I need logfiles, log reports, comands passed, ... I'm ready to integrate what you want, but be precise please.

Latest ebuild is here: ftp://ftp.mondorescue.org/gentoo/nover/test


Comment 55 Hans de Graaff gentoo-dev 2008-03-08 17:17:22 UTC
The latest version in tree, 2.10, fails like this:

>>> Unpacking source...
>>> Unpacking mondo-2.10.tgz to /var/tmp/portage/app-backup/mondo-rescue-2.10/work

gzip: stdin: decompression OK, trailing garbage ignored
tar: Child returned status 2
tar: Error exit delayed from previous errors
 * 
 * ERROR: app-backup/mondo-rescue-2.10 failed.
 * Call stack:
 *               ebuild.sh, line   49:  Called src_unpack
 *             environment, line  527:  Called unpack 'src_unpack'
 *               ebuild.sh, line  337:  Called die
 * The specific snippet of code:
 *   				tar xozf "${srcdir}${x}" ${tar_opts} || die "$myfail"
 *  The die message:
 *   failure unpacking mondo-2.10.tgz

This is with a freshly downloaded mondo-2.10.tgz.
Comment 56 Bruno Cornec 2008-03-09 10:30:06 UTC
2.10 IS NOT the version to look at:
It's obsolete and completely abandonned.

Please look at 2.2.5: ftp://ftp.mondorescue.org/gentoo/nover/test
And read that thread.
Comment 57 Hans de Graaff gentoo-dev 2008-03-09 10:51:52 UTC
I just wanted to clarify why Jakub was using terms like 'garbage' and 'completely fails' in relation to the ebuilds in the Gentoo tree, since you asked for the evidence of this.

I'd also like to point out that generally version 2.10 is considered to be newer than 2.2.5, and this may have added to the confusion that caused delays in updating the ebuilds in portage.

In any case, now that things are more clear, the next step seems to be for Wolfram to test the 2.2.5 ebuild and include it in the tree.
Comment 58 Liviu Andronic 2009-04-23 06:24:21 UTC
(In reply to comment #57)
> In any case, now that things are more clear, the next step seems to be for
> Wolfram to test the 2.2.5 ebuild and include it in the tree.
> 
New 2.2.8 version released in Feb [1]. 

[1] http://freshmeat.net/projects/mondorescue/
Comment 59 Bruno Cornec 2009-04-23 12:50:31 UTC
(In reply to comment #58)
> (In reply to comment #57)
> > In any case, now that things are more clear, the next step seems to be for
> > Wolfram to test the 2.2.5 ebuild and include it in the tree.
> > 
> New 2.2.8 version released in Feb [1]. 
> [1] http://freshmeat.net/projects/mondorescue/

And I continue to provide ebuilds available at 
ftp://ftp.mondorescue.org/gentoo/nover/
Comment 60 Talamona Francesco 2009-04-25 10:14:30 UTC
Please note that it should be named "mondo-rescue-2.2.8.ebuild"
to avoid clash with another program (sys-apps/mondo).

Anyway it is working well in my amd64
Portage 2.1.6.7 (default/linux/amd64/2008.0, gcc-4.3.2, glibc-2.8_p20080602-r1, 2.6.29-gentoo-r1 x86_64)
Comment 61 Bruno Cornec 2009-04-27 19:43:27 UTC
(In reply to comment #60)
> Please note that it should be named "mondo-rescue-2.2.8.ebuild"
> to avoid clash with another program (sys-apps/mondo).

In fact it's named mondo-rescue.ebuild which then redirects to the right content. Is it ok like that ?

> Anyway it is working well in my amd64
> Portage 2.1.6.7 (default/linux/amd64/2008.0, gcc-4.3.2, glibc-2.8_p20080602-r1, 2.6.29-gentoo-r1 x86_64)

Good to know ! Any way to reactivate now in gentoo ?

Comment 62 Helmut Eberharter 2009-05-07 21:25:00 UTC
Yeah! reactivate!
Comment 63 Robert Buchholz (RETIRED) gentoo-dev 2009-05-07 21:33:43 UTC
As far as I am concerned, not before you fix the handling of temporary files in there. The tool heavily relies on usage of the /tmp directory for both creation and recovery of the system. Recovery is not a problem, since this is usually done on single-user systems such as a live cd. However, handling temporary files insecurely when creating regular backups is not an option.

This issue is not nearly resolved in the latest version. Just do a grep and see for yourself.
Comment 64 Bruno Cornec 2009-05-07 22:20:48 UTC
(In reply to comment #63)
> As far as I am concerned, not before you fix the handling of temporary files in there. The tool heavily relies on usage of the /tmp directory for both creation and recovery of the system. Recovery is not a problem, since this is usually done on single-user systems such as a live cd. However, handling temporary files insecurely when creating regular backups is not an option.

I agree, but don't see what still need to be done here. there was a Debian bug aroud that, that I fixed long ago, and now people always seem to think there is an issue, where IMO there is no.

> This issue is not nearly resolved in the latest version. Just do a grep and see for yourself.

Well could you be a bit more precise ? I did that myself, and the /tmp reference I see are either for restore or below it another dir with the PID is created. 

I found one for parted2fdisk which indeed cause problem that I'll fix in SVN ASAP.

I may have miss some other when I fixed it globally, but again, I'd like to have precise points to look at rather than just the grep stuff (I do it myself but it's not providing the level of info you need - Is there a better tool BTW ?)



Comment 65 Mansour Moufid 2009-06-11 19:04:22 UTC
(In reply to comment #64)
> I agree, but don't see what still need to be done here. there was a Debian bug
> aroud that, that I fixed long ago, and now people always seem to think there is
> an issue, where IMO there is no.

I downloaded mondo-rescue-latest.tar.gz and looked at the source.

./mondo-rescue-2.2.7$ find src/ -type f -print0 | xargs -0 grep -A2 'LogIt()'
src/restore-scripts/mondo/format-and-kludge-vfat:LogIt() {
src/restore-scripts/mondo/format-and-kludge-vfat-    echo "$1" >> /dev/stderr
src/restore-scripts/mondo/format-and-kludge-vfat-}
--
src/restore-scripts/mondo/hack-fstab:LogIt() {
src/restore-scripts/mondo/hack-fstab-    echo "$1" >> /dev/stderr
src/restore-scripts/mondo/hack-fstab-}

So the LogIt() function is defined in those two files. However, it's also used 
elsewhere, where it is not declared:

./mondo-rescue-2.2.7$ find src/ -type f -print0 | xargs -0 grep 'LogIt' \
> | grep -v 'format-and-kludge-vfat' | grep -v 'hack-fstab' \
> | wc -l
166

I believe this is what Eric Romang was referring to originally when he said:
(In reply to comment #0)
> The LogIt function is not declared into this scripts.
> All this scripts should be removed.

I may be wrong, as the original advisory is no longer up and I've only just 
begun to look at this bug, but I will look into it further and maybe come up 
with a patch.
Comment 66 Bruno Cornec 2009-06-11 22:17:09 UTC
(In reply to comment #65)
> I downloaded mondo-rescue-latest.tar.gz and looked at the source.
> 
> ./mondo-rescue-2.2.7$ find src/ -type f -print0 | xargs -0 grep -A2 'LogIt()'
> src/restore-scripts/mondo/format-and-kludge-vfat:LogIt() {
> src/restore-scripts/mondo/format-and-kludge-vfat-    echo "$1" >> /dev/stderr
> src/restore-scripts/mondo/format-and-kludge-vfat-}
> --
> src/restore-scripts/mondo/hack-fstab:LogIt() {
> src/restore-scripts/mondo/hack-fstab-    echo "$1" >> /dev/stderr
> src/restore-scripts/mondo/hack-fstab-}
> 
> So the LogIt() function is defined in those two files. However, it's also used 
> elsewhere, where it is not declared:
> 
> ./mondo-rescue-2.2.7$ find src/ -type f -print0 | xargs -0 grep 'LogIt' \
> > | grep -v 'format-and-kludge-vfat' | grep -v 'hack-fstab' \
> > | wc -l
> 166

You're not looking at the right place as this function *is* declared in mindi:
113 victoria2.home.musique-ancienne.org-bruno ~/mondo/svn/branches/2.2.9 > find . -name LogIt
./mindi/rootfs/sbin/LogIt

> I believe this is what Eric Romang was referring to originally when he said:
> (In reply to comment #0)
> > The LogIt function is not declared into this scripts.
> > All this scripts should be removed.

That's why I continue to believe this is wrong, and that it should go on.
> 
> I may be wrong, as the original advisory is no longer up and I've only just 
> begun to look at this bug, but I will look into it further and maybe come up 
> with a patch.
> 

No patch needed.

Comment 67 Samuli Suominen gentoo-dev 2009-07-30 06:36:27 UTC
Adding treecleaners back. Masked since 13 Mar 2008. No progress has been made.

app-backup/mondo-rescue
sys-apps/mindi
sys-apps/mindi-busybox
Comment 68 Samuli Suominen gentoo-dev 2009-08-08 09:45:02 UTC
Removed from tree.