Re: linhdd concerns
On Thu, Nov 29, 2007 at 06:49:37AM +, Mike Hommey wrote: On Wed, Nov 28, 2007 at 02:19:21PM -0800, Russ Allbery wrote: Pierre Habouzit [EMAIL PROTECTED] writes: or we could disallow the override of = E: errors in lintian, and make lintian reboot your computer, fill your gpg with /dev/random bits, and install windows over your Debian if you override such errors. I'd love it if lintian were at a point where it would make sense to do that, but as a lintian maintainer, I'm afraid that it's not. Not all errors are created equal, and some of them should legitimately be overridable. We've talked for quite a while about having finer-grained control over lintian messages than the current three-tier system, in part to allow something like this (automatic dak rejection on certain lintian errors, for instance), but I'm way short on time. :/ For example, to take the lintian error that started this thread, there are some arch: all packages in the archive with architecture-specific objects that at least on a cursory glance I couldn't declare wrong. They're development packages for cross-compilation and the arch-specific objects are libraries for the target. That seems like a legitimate case for a lintian override to me. Also, BIOSes for emulators are candidates for such an override. I know, but maybe (but that's sad if we need to do that) we should have overrides validated by the QA people … *sigh*. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpLqejl3yhBB.pgp Description: PGP signature
Re: linhdd concerns
Pierre Habouzit [EMAIL PROTECTED] writes: I know, but maybe (but that's sad if we need to do that) we should have overrides validated by the QA people … *sigh*. Should the override file have a justification field for each (error) override? That would help generic DD's going through all override files. -- * Sufficiently advanced magic is indistinguishable from technology (T.P) * * PGP public key available @ http://www.iki.fi/killer *
Re: linhdd concerns
On Thu, Nov 29, 2007 at 11:08:33AM +, cobaco (aka Bart Cornelis) wrote: On Thursday 29 November 2007, Kalle Kivimaa wrote: Pierre Habouzit [EMAIL PROTECTED] writes: I know, but maybe (but that's sad if we need to do that) we should have overrides validated by the QA people … *sigh*. Should the override file have a justification field for each (error) override? That would help generic DD's going through all override files. override files allow comments which means giving a justification is already possible. So it seems this just needs to be documented as best practice? We definitely should have a lintian check for that !!! *cough* -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgprYKWIyuaGs.pgp Description: PGP signature
Re: linhdd concerns
On 29/11/2007, cobaco (aka Bart Cornelis) wrote: override files allow comments which means giving a justification is already possible. So it seems this just needs to be documented as best practice? Yes. -- Cyril Brulebois pgpwk92xgu5mY.pgp Description: PGP signature
Re: linhdd concerns (was: Re: Updated Debian Maintainers Keyring)
On Tue, Nov 27, 2007 at 06:55:10PM +1000, Anthony Towns wrote: aj, who'd just like to see some failure analysis / air crash investigation type conclusions out of this, rather than just foo sucks and shouldn't upload One thing we could do is have a seperate report on http://lintian.debian.org which lists all the lintian overrides (maybe only those for errors, not for warnings), so they can be peer reviewed by interested people. Another thing we could do is alert sponsors about checking for lintian overrides when they review a package. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linhdd concerns (was: Re: Updated Debian Maintainers Keyring)
On Wed, Nov 28, 2007 at 12:23:30PM +, Michael Banck wrote: On Tue, Nov 27, 2007 at 06:55:10PM +1000, Anthony Towns wrote: aj, who'd just like to see some failure analysis / air crash investigation type conclusions out of this, rather than just foo sucks and shouldn't upload One thing we could do is have a seperate report on http://lintian.debian.org which lists all the lintian overrides (maybe only those for errors, not for warnings), so they can be peer reviewed by interested people. Another thing we could do is alert sponsors about checking for lintian overrides when they review a package. or we could disallow the override of = E: errors in lintian, and make lintian reboot your computer, fill your gpg with /dev/random bits, and install windows over your Debian if you override such errors. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgptwTatMy2Tb.pgp Description: PGP signature
Re: linhdd concerns (was: Re: Updated Debian Maintainers Keyring)
On Wed, Nov 28, 2007 at 02:49:38PM +0100, Pierre Habouzit wrote: or we could disallow the override of = E: errors in lintian, and make lintian reboot your computer, fill your gpg with /dev/random bits, and install windows over your Debian if you override such errors. Are you routinely overriding valid lintian errors or why are you apparently so deeply horrified by peer review of lintian overrides? Pierre, bugs are nothing to be ashamed of. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linhdd concerns (was: Re: Updated Debian Maintainers Keyring)
On Wed, Nov 28, 2007 at 01:23:30PM +0100, Michael Banck wrote: On Tue, Nov 27, 2007 at 06:55:10PM +1000, Anthony Towns wrote: aj, who'd just like to see some failure analysis / air crash investigation type conclusions out of this, rather than just foo sucks and shouldn't upload One thing we could do is have a seperate report on http://lintian.debian.org which lists all the lintian overrides (maybe only those for errors, not for warnings), so they can be peer reviewed by interested people. Another thing we could do is alert sponsors about checking for lintian overrides when they review a package. #452804 -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] Since phone messaging became popular, the young generation has lost the ability to read or write anything that is longer than one hundred and sixty characters. -- Ignatios Souvatzis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linhdd concerns (was: Re: Updated Debian Maintainers Keyring)
On Wed, Nov 28, 2007 at 02:49:38PM +0100, Pierre Habouzit wrote: On Wed, Nov 28, 2007 at 12:23:30PM +, Michael Banck wrote: Another thing we could do is alert sponsors about checking for lintian overrides when they review a package. or we could disallow the override of = E: errors in lintian, and make lintian reboot your computer, fill your gpg with /dev/random bits, and install windows over your Debian if you override such errors. Interesting idea. I'd prefer to use a bit softer approach, if only because I wouldn't want to push our developers (DD or not) to non-free software, even if they misbehave. ;-) How about letting lintian report all messages always, with an extra note for overrides? Like this[0]: I: Override installed for the following message: I: W: pioneers binary: binary-without-manpage usr/games/pioneers-editor With -i, the first line should expand to something like: I: Override installed for the following message: I: The maintainer installed an override for the following error. This I: means that lintian is wrong about this, and there is nothing wrong I: with the package. Or perhaps a little less maintainer-friendly, suggesting that the override could be incorrect. :-) AFAIK there are three solutions for handling a lintian message: - If the package is indeed broken, fix it. The most usual. - If lintian is broken, report a bug and/or fix it and submit a patch. In the mean time, ignore the message. Not so usual. - If lintian is not right, but this is such a weird cornercase that it is not reasonable to expect that, install an override. Very unusual. This means that lintian overrides should be very rare. And it is no problem to get messages like above for them. Thanks, Bas [0] Ok, this is not something that should be overridden, but I wanted to use my own package, and I don't think I have any overrides installed anywhere. -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
Re: linhdd concerns (was: Re: Updated Debian Maintainers Keyring)
On Wed, Nov 28, 2007 at 02:49:38PM +0100, Pierre Habouzit wrote: On Wed, Nov 28, 2007 at 12:23:30PM +, Michael Banck wrote: On Tue, Nov 27, 2007 at 06:55:10PM +1000, Anthony Towns wrote: aj, who'd just like to see some failure analysis / air crash investigation type conclusions out of this, rather than just foo sucks and shouldn't upload One thing we could do is have a seperate report on http://lintian.debian.org which lists all the lintian overrides (maybe only those for errors, not for warnings), so they can be peer reviewed by interested people. Another thing we could do is alert sponsors about checking for lintian overrides when they review a package. or we could disallow the override of = E: errors in lintian, and make lintian reboot your computer, fill your gpg with /dev/random bits, and install windows over your Debian if you override such errors. Then tag as wontfix when someone reports the bug on lintian? Or just claim that it's a feature, not a bug? -- Brett Parker -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linhdd concerns (was: Re: Updated Debian Maintainers Keyring)
Michael Banck [EMAIL PROTECTED] writes: On Tue, Nov 27, 2007 at 06:55:10PM +1000, Anthony Towns wrote: aj, who'd just like to see some failure analysis / air crash investigation type conclusions out of this, rather than just foo sucks and shouldn't upload One thing we could do is have a seperate report on http://lintian.debian.org which lists all the lintian overrides (maybe only those for errors, not for warnings), so they can be peer reviewed by interested people. Another thing we could do is alert sponsors about checking for lintian overrides when they review a package. I would also suggest adding afew lines in the developer reference under section 7.5.2 with those suggestions that evolved out of this thread. I will file a wishlist bug against developers-reference. -- Ramakrishnan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linhdd concerns (was: Re: Updated Debian Maintainers Keyring)
On Wed, Nov 28, 2007 at 02:54:39PM +, Michael Banck wrote: On Wed, Nov 28, 2007 at 02:49:38PM +0100, Pierre Habouzit wrote: or we could disallow the override of = E: errors in lintian, and make lintian reboot your computer, fill your gpg with /dev/random bits, and install windows over your Debian if you override such errors. Are you routinely overriding valid lintian errors or why are you apparently so deeply horrified by peer review of lintian overrides? Pierre, bugs are nothing to be ashamed of. You must have misunderstood me. I believe that allowing anyone to override some kinds of lintian warnings should just be disallowed, because there's no way such a thing is correct. Or so seldomly that packagers for whom it's the case can live with a warning. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpvfWXmvbzWN.pgp Description: PGP signature
Re: linhdd concerns (was: Re: Updated Debian Maintainers Keyring)
Bas Wijnen dijo [Wed, Nov 28, 2007 at 04:51:30PM +0100]: or we could disallow the override of = E: errors in lintian, and make lintian reboot your computer, fill your gpg with /dev/random bits, and install windows over your Debian if you override such errors. Interesting idea. I'd prefer to use a bit softer approach, if only because I wouldn't want to push our developers (DD or not) to non-free software, even if they misbehave. ;-) Besides, I somehow doubt this would be legal or enforceable on all jurisdiction. Just as an example, I doubt it would be legal and enforceable for Lintian to install Windows on my PPC machines. How about letting lintian report all messages always, with an extra note for overrides? Like this[0]: I: Override installed for the following message: I: W: pioneers binary: binary-without-manpage usr/games/pioneers-editor With -i, the first line should expand to something like: I: Override installed for the following message: I: The maintainer installed an override for the following error. This I: means that lintian is wrong about this, and there is nothing wrong I: with the package. Or perhaps a little less maintainer-friendly, suggesting that the override could be incorrect. :-) +1 to this. Overriden Lintian messages should be infrequent, as you say, and the overrides should just demote the message to the point it does not bother the person building anymore, but automated tools (and fellow humans building the package, i.e. to sponsor, NMU or adopt it) should nonetheless know there is _something_ Lintian does not like. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF pgpPM1acy66Tf.pgp Description: PGP signature
Re: linhdd concerns (was: Re: Updated Debian Maintainers Keyring)
On 2007-11-28, Bas Wijnen [EMAIL PROTECTED] wrote: On Wed, Nov 28, 2007 at 02:49:38PM +0100, Pierre Habouzit wrote: On Wed, Nov 28, 2007 at 12:23:30PM +, Michael Banck wrote: Another thing we could do is alert sponsors about checking for lintian overrides when they review a package. =20 or we could disallow the override of =3D E: errors in lintian, and make lintian reboot your computer, fill your gpg with /dev/random bits, and install windows over your Debian if you override such errors. Interesting idea. I'd prefer to use a bit softer approach, if only because I wouldn't want to push our developers (DD or not) to non-free software, even if they misbehave. ;-) How about letting lintian report all messages always, with an extra note for overrides? Like this[0]: A too verbose lintian makes people overlook the real issues. Some time ago, lintian was too strict about .desktop files and made the kdegraphics source package spew more than 700 lines of lintian warnings and errors. (lintian has now gotten more accurate) Those 700 lines of stuff made lintian effectively unusable for those packages. Overrides are meant to make stuff not be shown. Please let it be that way and instead educate sponsors to look at installed overrides. Lintian even has a switch to ignore overrides and output everything - sponsors should use that. /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linhdd concerns
Michael Banck [EMAIL PROTECTED] writes: One thing we could do is have a seperate report on http://lintian.debian.org which lists all the lintian overrides (maybe only those for errors, not for warnings), so they can be peer reviewed by interested people. I've been wanting to add overrides and info tags to the lintian.d.o pages for some time and just haven't had the time to work on the scripts. Patches are definitely welcome. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linhdd concerns
On Wed, Nov 28, 2007 at 02:19:21PM -0800, Russ Allbery wrote: Pierre Habouzit [EMAIL PROTECTED] writes: or we could disallow the override of = E: errors in lintian, and make lintian reboot your computer, fill your gpg with /dev/random bits, and install windows over your Debian if you override such errors. I'd love it if lintian were at a point where it would make sense to do that, but as a lintian maintainer, I'm afraid that it's not. Not all errors are created equal, and some of them should legitimately be overridable. We've talked for quite a while about having finer-grained control over lintian messages than the current three-tier system, in part to allow something like this (automatic dak rejection on certain lintian errors, for instance), but I'm way short on time. :/ For example, to take the lintian error that started this thread, there are some arch: all packages in the archive with architecture-specific objects that at least on a cursory glance I couldn't declare wrong. They're development packages for cross-compilation and the arch-specific objects are libraries for the target. That seems like a legitimate case for a lintian override to me. Also, BIOSes for emulators are candidates for such an override. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linhdd concerns (was: Re: Updated Debian Maintainers Keyring)
On Mon, Nov 26, 2007 at 09:44:50PM +0530, Ramakrishnan Muthukrishnan wrote: As people have already explained, this is not the first mistake people have commited. And at the same time, I agree that it was a grave mistake on my part and I publicly apologize for this mistake. If you care to rectify this by removing my account, by all means do so. Right, and it won't be the last either -- but it seems to me the best approach is to prevent similar bugs from happening again. Unless there's some hidden mass of problems in packages you sponsor (and I imagine it would've become apparent by now if there were), removing your account or upload rights or ability to sponsor wouldn't actually be an improvement. But there has to be *something* that could reasonably have been done to avoid this mistake, that you and other sponsors could just make part of your routine in future so *this* mistake doesn't happen again. I've suggested some ways that might work, but your thoughts on the matter would seem much more useful, both since this was your mistake, and because you're much more actively involved in sponsoring than I am. Cheers, aj, who'd just like to see some failure analysis / air crash investigation type conclusions out of this, rather than just foo sucks and shouldn't upload signature.asc Description: Digital signature
Re: linhdd concerns
Steve Langasek wrote: No, that would be a security hole. Even making it setgid disk would be a security hole, since the disk group has write access to all disk devices. I didn't mean a simple wrapper around the binary, I meant a wrapper around the binary with a specific set of arguments, locking the used to a single read-only operation (which seems to be what the front end needs). Now that you mention it, my original thought would still pose a security threat in case the fdisk could somehow be exploited through the wrapper, but then again this is precisely the same level of security any other setuid binary in the system has. Cheers -- Leo costela Antunes [insert a witty retort here] signature.asc Description: OpenPGP digital signature
Re: linhdd concerns
On Mon, Nov 26, 2007 at 11:38:06PM -0800, Steve Langasek wrote:
On Mon, Nov 26, 2007 at 09:51:35PM +0100, Leo costela Antunes wrote:
What information does linhdd need from fdisk?
Fdisk seems to run just fine as a normal user on Debian. The issues
seems to be that /dev/{s,h}d* are directly readable only by members of
the group 'disk'.
Perhaps instead of packaging this 'abs_fdisk', which AFAICT is just a
read-only non-root fdisk, you could just create a setuid wrapper to
the normal fdisk and use it from linhdd?
No, that would be a security hole. Even making it setgid disk would be a
security hole, since the disk group has write access to all disk devices.
The idea of the wrapper would of course be that it would only allow read
access, so the write access is not a problem.
If I understand the case correctly, abs_fdisk is a modified read-only
setuid root version of fdisk, which is used by linhdd to get some info
which is also available to everyone under /proc. Providing this info is
obviously not a security problem (as long as abs_fdisk is not buggy).
However, a read-only version of fdisk can likely get much more info
than just what is available in /proc. The fact that linhdd doesn't use
that doesn't make it unavailable. It seems to me that this approach
introduces security issues (allowing read access that shouldn't be
allowed, plus an extra setuid root (or setgid disk) binary which must
not be buggy) that should better be avoided.
Would it be very hard to write a script which does the same as abs_fdisk
(and can be used as a drop-in replacement), but gets its info from
/proc, and doesn't need elevated permissions?
Thanks,
Bas
--
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html
signature.asc
Description: Digital signature
Re: linhdd concerns
[ late, but for the records. ] Kartik Mistry wrote: linhdd introduce binary abs_fdisk which was modified copy of fdisk from new version 0.4. It was arch:all before that too, and previous maintainer set it to arch:all saying 'it will save achieve space'. hu?? the previous maintainer, me, did set arch all because the package *was* arch all only, it did not contain any architecture depended data at all- it is just a script (up to 0.3-3; no clue what you/upstream did afterwards). As suggested to me, I did removal of linhdd. To fix this bug, we have to build util-linux and I think its too much and probably wrong to have fdisk stay in /usr/bin. why not just having uploaded the last sane version with an epoche? then, you could have took your time to fix the 0.4 version properly.. it's bad to see 'my' package go just because of that.. -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: [EMAIL PROTECTED] Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linhdd concerns (was: Re: Updated Debian Maintainers Keyring)
On Sat, Nov 24, 2007 at 11:22:52PM +0530, Ramakrishnan Muthukrishnan wrote: [I did not recieve the original email addressed to me by aj, so I am literally reading between the lines to digest the original message] It was sent to your @d.o address, and is in the list archives at: http://lists.debian.org/debian-project/2007/11/msg00145.html Ramakrishnan, how did your sponsorship checking miss both this error and the RC bug (442093) the previous upload introduced by the i386 binary's absence? I have tried to catch and feed the lintian and linda errors back to Kartik all the time. I really don't know how I missed it. Well, it was overriden, so unless you'd use lintian with --show-overrides, it wouldn't've shown up. If I remember right, I did an upload of this package only once. You sponsored both the 0.4-1 and 0.4-2 uploads according to the signatures on the .changes files [0]. AFAICS, there were three places where, as sponsor, you could have picked this issue up: - in the 0.4-1 upload, you should have found that the program didn't work at all after being built, ie spotted Bug#442093 prior to uploading; working more closely with Kartik in solving that bug might have avoided including abs_fdisk at all - in the 0.4-2 upload, you should've seen the changelog entry added abs_fdisk binary and wondered why a binary was being added to an arch:all package. Or why it wasn't using fdisk from util-linux. - in the 0.4-2 upload, you might've looked at the debdiff against 0.4-1 and noticed the addition of the debian/lintian.override file containing: linhdd: arch-independent-package-contains-binary-or-object ./usr/bin/abs_fdisk and asked what was going on. Please go ahead with my upload rights removal and also removal from debian keyring, if you judje people by just one of their actions. In this case it's inaction, and it'd be better if you'd acknowledge the problem and do what you can to avoid it in future. From the above, it seems like when sponsoring packages you're not always: - testing to see if they work - reviewing the changelog with an eye for problems - running debdiff to see if anything looks odd - agreeing to sponsor packages only when you've got time to review them That's only my inference from the results though; maybe you are doing some or all of the above normally, and just slipped up this time. Or maybe you have some other technique to catch problems that makes more sense than the above? Removal of your upload rights is one way of avoiding this mistake in future, but there are lots of other sponsors who could make the same mistake, and given you sponsor other things, it has a lot of collateral damage... Cheers, aj [0] [EMAIL PROTECTED]:/srv/ftp.debian.org/queue/done$ gpgv \ --keyring /srv/keyring.debian.org/keyrings/debian-keyring.gpg \ 2007/09/06/linhdd_0.4-1_amd64.changes gpgv: Signature made Thu Sep 6 11:01:25 2007 MDT using DSA key ID 6A9F3C38 gpgv: Good signature from Ramakrishnan M [EMAIL PROTECTED] ... [EMAIL PROTECTED]:/srv/ftp.debian.org/queue/done$ gpgv \ --keyring /srv/keyring.debian.org/keyrings/debian-keyring.gpg \ 2007/09/19/linhdd_0.4-2_amd64.changes gpgv: Signature made Wed Sep 19 10:19:22 2007 MDT using DSA key ID 6A9F3C38 gpgv: Good signature from Ramakrishnan M [EMAIL PROTECTED] ... signature.asc Description: Digital signature
Re: linhdd concerns (was: Re: Updated Debian Maintainers Keyring)
On Nov 26, 2007 8:57 PM, Anthony Towns [EMAIL PROTECTED] wrote: In this case it's inaction, and it'd be better if you'd acknowledge the problem and do what you can to avoid it in future. From the above, it seems like when sponsoring packages you're not always: - testing to see if they work - reviewing the changelog with an eye for problems - running debdiff to see if anything looks odd - agreeing to sponsor packages only when you've got time to review them aj, As I already explained, Kartik sent me loads of packages to check for and almost all the time after afew initial mistakes, he did a good job, so perhaps I missed looking into this package more closely. As people have already explained, this is not the first mistake people have commited. And at the same time, I agree that it was a grave mistake on my part and I publicly apologize for this mistake. If you care to rectify this by removing my account, by all means do so. Ramakrishnan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linhdd concerns
Anthony Towns [EMAIL PROTECTED] writes: ] I could use fdisk. Just that on Slackware and Absolute, which I use, ] you can only run fdisk as root. So -- I downloaded util-linux and makes it sound to me like you should be packaging abs_fdisk separately and having linhdd Depend: on it; or, ideally, getting util-linux patched so its fdisk can support the same features as abs_fdisk. No, all you really need to do is to have linhdd depend on util-linux and use simply fdisk -l /dev/sda. Works just fine, provided the user has read rights on the device (and if the user doesn't, it doesn't matter *which* program tries to read the data). -- * Sufficiently advanced magic is indistinguishable from technology (T.P) * * PGP public key available @ http://www.iki.fi/killer * -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linhdd concerns
Anthony Towns wrote:
Given the description of abs_fdisk on the linhdd site:
] 0.4 release now includes a customized version of fdisk (called
] abs_fdisk). Why? Well, daealing with SATA (scsi) in /proc was a bear --
] and the ease with which fdisk gave me the needed drive info made me wish
] I could use fdisk. Just that on Slackware and Absolute, which I use,
] you can only run fdisk as root. So -- I downloaded util-linux and
] changed the source code for fdisk so that it would not srite anythig
] to drives, just return the drive info. Renamed it abs_fdisk (because I
] wrote it sort of specifically for Absolute Linux, and Eureka!, Use fdisk
] as non-root user safely.
makes it sound to me like you should be packaging abs_fdisk separately and
having linhdd Depend: on it; or, ideally, getting util-linux patched so
its fdisk can support the same features as abs_fdisk.
What information does linhdd need from fdisk?
Fdisk seems to run just fine as a normal user on Debian. The issues
seems to be that /dev/{s,h}d* are directly readable only by members of
the group 'disk'.
Perhaps instead of packaging this 'abs_fdisk', which AFAICT is just a
read-only non-root fdisk, you could just create a setuid wrapper to
the normal fdisk and use it from linhdd?
Cheers
--
Leo costela Antunes
[insert a witty retort here]
signature.asc
Description: OpenPGP digital signature
Re: linhdd concerns
On Mon, Nov 26, 2007 at 09:51:35PM +0100, Leo costela Antunes wrote:
Anthony Towns wrote:
Given the description of abs_fdisk on the linhdd site:
] 0.4 release now includes a customized version of fdisk (called
] abs_fdisk). Why? Well, daealing with SATA (scsi) in /proc was a bear --
] and the ease with which fdisk gave me the needed drive info made me wish
] I could use fdisk. Just that on Slackware and Absolute, which I use,
] you can only run fdisk as root. So -- I downloaded util-linux and
] changed the source code for fdisk so that it would not srite anythig
] to drives, just return the drive info. Renamed it abs_fdisk (because I
] wrote it sort of specifically for Absolute Linux, and Eureka!, Use fdisk
] as non-root user safely.
makes it sound to me like you should be packaging abs_fdisk separately and
having linhdd Depend: on it; or, ideally, getting util-linux patched so
its fdisk can support the same features as abs_fdisk.
What information does linhdd need from fdisk?
Fdisk seems to run just fine as a normal user on Debian. The issues
seems to be that /dev/{s,h}d* are directly readable only by members of
the group 'disk'.
Perhaps instead of packaging this 'abs_fdisk', which AFAICT is just a
read-only non-root fdisk, you could just create a setuid wrapper to
the normal fdisk and use it from linhdd?
No, that would be a security hole. Even making it setgid disk would be a
security hole, since the disk group has write access to all disk devices.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
[EMAIL PROTECTED] [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [D-m-team] linhdd concerns
Marc 'HE' Brockschmidt wrote: That's a bit weird. He produces a package with a major bug, ignores *all* hints by lintian and is now rewarded for that by getting upload permissions? It's also a bit weird for someone to have their upload ability immediately removed for making any sort of technical mistake. This is not the worst[1] mistake I've seen uploaded, nor is it the first time I've seen a maintainer ignore lintian errors. (With that said, it looks like Myon has removed him.) Also, perhaps this event is a sign that the current review process is not perfect yet. Do you mean the sponsorship review process, or the DM review process? The worst thing about this to my mind is that the package got sponsored into the archive over a month ago. As for DM review, DMs are not supposed to need to know everything that TS would test. They're supposed to still be learning, and the DM process is supposed to be more lightweight than the newmaint process. So it's ok for a DM to not know how to limit an arch dependent package to only build on a given set of architectures. It's clearly not acceptable for them to have created a package a month ago that papers over lintian errors about including a precompiled binary in an arch indep package. The most important data I have when I'm reviewing a DM is the advocacy messages. If I see the AM say, he's already nearly passed Tasks and Skills and a sponsor say, diligent in looking after his packages and dealing with bug reports, I have to assume the first adovocacy statement is accurate, and it's tempting to also assume the second statement is accurate. I did look at Kartik's open bugs before accepting him, but the bug hadn't been filed yet. It's important that these messages be detailed and accurate. If someone needs to review a DM's existing packages in detail before they are added, I'd hope the advocates could do that, and discuss the review in their advocacy messages. But would such a review be any better than the review the DM's sponsor should have performed before uploading their package in the first place? -- see shy jo [1] The time I uploaded a menu-method file that accidentially did a rm -rf $FOO/$BAR (FOO=BAR=) as root is my favorite horrible, deadful, should have gotten me banned from Debian for life mistake. signature.asc Description: Digital signature
Re: linhdd concerns (was: Re: Updated Debian Maintainers Keyring)
On Sun, Nov 25, 2007, Anthony Towns wrote: Mohammed and Jaldhar, as advocates (and AM) of Kartik, do you have anything to add here? What I have to add is: 1) Kartik is very reactive in correcting his packages when an error is found 2) Kartik has not finished NM yet as I have to check (all) his packages; my advocacy was based on the quality of the packages I've already checked (linhdd is not one of them) or sponsored -- Mohammed Adnène Trojette -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
linhdd concerns (was: Re: Updated Debian Maintainers Keyring)
Hi Ramakrishnan, Mohammed, Jaldhar, Kartik, It's been pointed out that Kartik's latest upload of linhdd has included an i386 binary in arch:all package, and explicitly overriden the lintian warning for it (see the mail quoted below). That seems pretty dodgy. Kartik what possible reason did you have for overriding the lintian error report, rather than changing your package to remove the error? Did you ask anyone's advice before doing so? Why are you asking for the removal of linhdd now (Bug#452629), instead of *fixing* the package, eg, by making the package architecture specific instead of arch:all and either the binary built as part of debian/rules, or simply using the fdisk that's already packaged as part of util-linux? Ramakrishnan, how did your sponsorship checking miss both this error and the RC bug (442093) the previous upload introduced by the i386 binary's absence? Mohammed and Jaldhar, as advocates (and AM) of Kartik, do you have anything to add here? For the record, Ramakrishnan also seems to have sponsored uploads of the following packages for Kartik that are still present in the archive: of festival, festival-doc, fontypython, speech-tools, tagtool, and uni2ascii. His only other sponsored upload still in the archive is kpsk 1.0.1-3 in sarge for Sebastian Muszynski. Kartik is listed as maintainer of: aspell-gu | Kartik Mistry [EMAIL PROTECTED] ayttm | Kartik Mistry [EMAIL PROTECTED] bake | Kartik Mistry [EMAIL PROTECTED] blast | Kartik Mistry [EMAIL PROTECTED] chmlib | Kartik Mistry [EMAIL PROTECTED] clara | Kartik Mistry [EMAIL PROTECTED] dvdrtools | Kartik Mistry [EMAIL PROTECTED] festival | Kartik Mistry [EMAIL PROTECTED] festival-doc | Kartik Mistry [EMAIL PROTECTED] fontypython| Kartik Mistry [EMAIL PROTECTED] freetalk | Kartik Mistry [EMAIL PROTECTED] gnome-specimen | Kartik Mistry [EMAIL PROTECTED] gtkdiskfree| Kartik Mistry [EMAIL PROTECTED] kphotobymail | Kartik Mistry [EMAIL PROTECTED] ldtp | Kartik Mistry [EMAIL PROTECTED] ldtp-doc | Kartik Mistry [EMAIL PROTECTED] libyahoo2 | Kartik Mistry [EMAIL PROTECTED] linhdd | Kartik Mistry [EMAIL PROTECTED] mpy-svn-stats | Kartik Mistry [EMAIL PROTECTED] pygtkmvc | Kartik Mistry [EMAIL PROTECTED] pyslide| Kartik Mistry [EMAIL PROTECTED] recoll | Kartik Mistry [EMAIL PROTECTED] scanmem| Kartik Mistry [EMAIL PROTECTED] sitecopy | Kartik Mistry [EMAIL PROTECTED] speech-tools | Kartik Mistry [EMAIL PROTECTED] tagtool| Kartik Mistry [EMAIL PROTECTED] tepache| Kartik Mistry [EMAIL PROTECTED] uni2ascii | Kartik Mistry [EMAIL PROTECTED] xchm | Kartik Mistry [EMAIL PROTECTED] xmms-crossfade | Kartik Mistry [EMAIL PROTECTED] xmountains | Kartik Mistry [EMAIL PROTECTED] xosview| Kartik Mistry [EMAIL PROTECTED] On Fri, Nov 23, 2007 at 06:49:24PM +, Steve McIntyre wrote: dm:[EMAIL PROTECTED] Full name: Kartik Mistry I don't know if that was such a good idea, see #452464 Wow, the linhdd package is *special*. Based on initial analysis of this package, please remove: * the DM (Kartik Mistry) from the keyring (he clearly needs to learn more before he should be allowed to upload directly) * the upload rights of the sponsor (Ramakrishnan M [EMAIL PROTECTED]) who uploaded this to incoming without any suitable level of checking. This is a *much* more important problem IMHO. * the package itself The package contains an i386 binary (abs_fdisk)in a binary-all package, directly installed from a binary that comes in the upstream source packages. To accompany that, there are the following highlights: * a README.Debian stating linhdd also has binary called 'abs_fdisk' which is used for linhdd working correctly. util-linux is provided for its source. To save archive space, the package is set to Architecture: all. Please do not report this as a bug on the mentioned architectures. * a lintian.override file to suppress errors about it * changed source files that claim to be used in fdisk and abs_fdisk I expect a *much* higher standard of packages in our archive, and I hope I'm not alone here. Cheers, aj signature.asc Description: Digital signature
Re: linhdd concerns (was: Re: Updated Debian Maintainers Keyring)
On Nov 24, 2007 7:44 PM, Anthony Towns [EMAIL PROTECTED] wrote: Hi Ramakrishnan, Mohammed, Jaldhar, Kartik, Hi all, Please read me inline. It's been pointed out that Kartik's latest upload of linhdd has included an i386 binary in arch:all package, and explicitly overriden the lintian warning for it (see the mail quoted below). That seems pretty dodgy. Yes. Its pretty bad. I agree. And deeply apologize. Kartik what possible reason did you have for overriding the lintian error report, rather than changing your package to remove the error? linhdd introduce binary abs_fdisk which was modified copy of fdisk from new version 0.4. It was arch:all before that too, and previous maintainer set it to arch:all saying 'it will save achieve space'. Since, it was working fine with 0.3, linhdd now depends on modified copy of fdisk, abs_fdisk. I fixed this by adding upstream provided copy of it. Did you ask anyone's advice before doing so? Why are you asking for the removal of linhdd now (Bug#452629), instead of *fixing* the package, eg, by making the package architecture specific instead of arch:all and either the binary built as part of debian/rules, or simply using the fdisk that's already packaged as part of util-linux? As suggested to me, I did removal of linhdd. To fix this bug, we have to build util-linux and I think its too much and probably wrong to have fdisk stay in /usr/bin. Ramakrishnan, how did your sponsorship checking miss both this error and the RC bug (442093) the previous upload introduced by the i386 binary's absence? Mohammed and Jaldhar, as advocates (and AM) of Kartik, do you have anything to add here? For the record, Ramakrishnan also seems to have sponsored uploads of the following packages for Kartik that are still present in the archive: of festival, festival-doc, fontypython, speech-tools, tagtool, and uni2ascii. His only other sponsored upload still in the archive is kpsk 1.0.1-3 in sarge for Sebastian Muszynski. Kartik is listed as maintainer of: aspell-gu | Kartik Mistry [EMAIL PROTECTED] ayttm | Kartik Mistry [EMAIL PROTECTED] bake | Kartik Mistry [EMAIL PROTECTED] blast | Kartik Mistry [EMAIL PROTECTED] chmlib | Kartik Mistry [EMAIL PROTECTED] clara | Kartik Mistry [EMAIL PROTECTED] dvdrtools | Kartik Mistry [EMAIL PROTECTED] festival | Kartik Mistry [EMAIL PROTECTED] festival-doc | Kartik Mistry [EMAIL PROTECTED] fontypython| Kartik Mistry [EMAIL PROTECTED] freetalk | Kartik Mistry [EMAIL PROTECTED] gnome-specimen | Kartik Mistry [EMAIL PROTECTED] gtkdiskfree| Kartik Mistry [EMAIL PROTECTED] kphotobymail | Kartik Mistry [EMAIL PROTECTED] ldtp | Kartik Mistry [EMAIL PROTECTED] ldtp-doc | Kartik Mistry [EMAIL PROTECTED] libyahoo2 | Kartik Mistry [EMAIL PROTECTED] linhdd | Kartik Mistry [EMAIL PROTECTED] mpy-svn-stats | Kartik Mistry [EMAIL PROTECTED] pygtkmvc | Kartik Mistry [EMAIL PROTECTED] pyslide| Kartik Mistry [EMAIL PROTECTED] recoll | Kartik Mistry [EMAIL PROTECTED] scanmem| Kartik Mistry [EMAIL PROTECTED] sitecopy | Kartik Mistry [EMAIL PROTECTED] speech-tools | Kartik Mistry [EMAIL PROTECTED] tagtool| Kartik Mistry [EMAIL PROTECTED] tepache| Kartik Mistry [EMAIL PROTECTED] uni2ascii | Kartik Mistry [EMAIL PROTECTED] xchm | Kartik Mistry [EMAIL PROTECTED] xmms-crossfade | Kartik Mistry [EMAIL PROTECTED] xmountains | Kartik Mistry [EMAIL PROTECTED] xosview| Kartik Mistry [EMAIL PROTECTED] On Fri, Nov 23, 2007 at 06:49:24PM +, Steve McIntyre wrote: dm:[EMAIL PROTECTED] Full name: Kartik Mistry I don't know if that was such a good idea, see #452464 Wow, the linhdd package is *special*. Based on initial analysis of this package, please remove: * the DM (Kartik Mistry) from the keyring (he clearly needs to learn more before he should be allowed to upload directly) * the upload rights of the sponsor (Ramakrishnan M [EMAIL PROTECTED]) who uploaded this to incoming without any suitable level of checking. This is a *much* more important problem IMHO. * the package itself The package contains an i386 binary (abs_fdisk)in a binary-all package, directly installed from a binary that comes in the upstream source packages. To accompany that, there are the following highlights: * a README.Debian stating linhdd also has binary called 'abs_fdisk' which is used for linhdd working correctly. util-linux is provided for its source. To save archive space, the package is set to Architecture: all. Please do not report this as a bug on the mentioned architectures. * a lintian.override file to suppress errors about it * changed source files that claim to be used in fdisk and abs_fdisk I expect a *much* higher standard of packages in
Re: linhdd concerns (was: Re: Updated Debian Maintainers Keyring)
On Sun, 25 Nov 2007, Anthony Towns wrote: Mohammed and Jaldhar, as advocates (and AM) of Kartik, do you have anything to add here? Mainly I have worked with Kartik on Debian-IN packages and there I have no complaints. Lately, I have been sponsoring some of his other packages and on the occasions that I have spotted packaging problems (few, and none as bad as this.) Kartik has fixed them and not repeated the error. As I suggested on IRC yesterday, maybe he should cut down on the amount of packages he is maintaining and drop some of the more complicated ones but I do think he is capable of maintaining packages on his own in general. -- Jaldhar H. Vyas [EMAIL PROTECTED] La Salle Debain - http://www.braincells.com/debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linhdd concerns (was: Re: Updated Debian Maintainers Keyring)
[I did not recieve the original email addressed to me by aj, so I am literally reading between the lines to digest the original message] Kartik Mistry [EMAIL PROTECTED] writes: Ramakrishnan, how did your sponsorship checking miss both this error and the RC bug (442093) the previous upload introduced by the i386 binary's absence? I have tried to catch and feed the lintian and linda errors back to Kartik all the time. I really don't know how I missed it. If I remember right, I did an upload of this package only once. As a matter of fact, I was a bit overwhelmed by the number of requests for package uploads from Kartik, so it may have so happened that I did it by in haste and missed this error. I apologize for the error. For the last few sponsored uploads of Kartik, I have only uploaded festival and associated packages, not linhdd. On Fri, Nov 23, 2007 at 06:49:24PM +, Steve McIntyre wrote: dm:[EMAIL PROTECTED] Full name: Kartik Mistry I don't know if that was such a good idea, see #452464 Wow, the linhdd package is *special*. Based on initial analysis of this package, please remove: * the DM (Kartik Mistry) from the keyring (he clearly needs to learn more before he should be allowed to upload directly) * the upload rights of the sponsor (Ramakrishnan M [EMAIL PROTECTED]) who uploaded this to incoming without any suitable level of checking. This is a *much* more important problem IMHO. Please go ahead with my upload rights removal and also removal from debian keyring, if you judje people by just one of their actions. Thanks -- Ramakrishnan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linhdd concerns (was: Re: Updated Debian Maintainers Keyring)
On Sun, 2007-11-25 at 00:14 +1000, Anthony Towns wrote: Mohammed and Jaldhar, as advocates (and AM) of Kartik, do you have anything to add here? Out of Kartik's NM page: Application Manager Comments PP1: [done] 20070417 PP2: [done] 20070529 TS1: [done] 20070812 TS2: [done] 20071007 packages checking... I don't know until what point the NM process can actually be hacked. -- David Moreno Garza [EMAIL PROTECTED] | http://www.damog.net/ Y es que me gusta tanto tu pelo. signature.asc Description: This is a digitally signed message part
Re: linhdd concerns (was: Re: Updated Debian Maintainers Keyring)
Jaldhar H. Vyas dijo [Sat, Nov 24, 2007 at 11:13:29AM -0500]: Mohammed and Jaldhar, as advocates (and AM) of Kartik, do you have anything to add here? Mainly I have worked with Kartik on Debian-IN packages and there I have no complaints. Lately, I have been sponsoring some of his other packages and on the occasions that I have spotted packaging problems (few, and none as bad as this.) Kartik has fixed them and not repeated the error. As I suggested on IRC yesterday, maybe he should cut down on the amount of packages he is maintaining and drop some of the more complicated ones but I do think he is capable of maintaining packages on his own in general. I have sponsored several of Kartik's uploads as well, regarding xosview (for which I am the previous maintainer). Some months ago, yes, Kartik needed quite a bit of hand-holding. As of now, however, I do agree his packaging (on what I have seen - this means, on xosview) _is_ of enough quality. So... Well, I do hope this public flaming regarding the fdisk messup is enough to fix the mistake (not minor by any means, but still a mistake) he did. Of course, as sponsors we are meant to check the uploaded packages do build and work correctly, and as a sponsoree/trainee he should be very careful when playing with overrides (in most cases, lintian/linda _do_ know best!)... ...But I do feel he should be given the DM privileges. And, of course, Kartik, please keep your eyes open! ;-) Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF pgp4h6WTihtwL.pgp Description: PGP signature
