Bug#927885: stretch: apt-get mysteriously fails

[Raul Miller]

Package: apt
Version: 1.4.8
Severity: important

I tried to install a package which is documented to exist and that install 
attempt consistently failed (though apt seems to work normally most of the rest 
of the time):

# apt-get install php-imagick
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Package php-imagick is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Package 'php-imagick' has no installation candidate
# cat /etc/apt/sources.list
deb http://deb.debian.org/debian stretch main
deb http://security.debian.org/debian-security stretch/updates main
deb http://deb.debian.org/debian stretch-updates main
# apt-get install liblz4-tool

...(that install attempt worked)...

# lz4 -d 

Architecture: amd64
Provides: php7.0-imagick
Depends: php-common (>= 1:7.0+33~), phpapi-20151012, libc6 (>= 2.14), 
libmagickcore-6.q16-3 (>= 8:6.9.6.8), libmagickwand-6.q16-3 (>= 8:6.9.6.8)
Recommends: ghostscript, ttf-dejavu-core
Description: Provides a wrapper to the ImageMagick library
Homepage: http://pecl.php.net/package/imagick
Description-md5: bc43e2599d98ae7eb5833a5ff7056545
Section: php
Priority: optional
Filename: pool/main/p/php-imagick/php-imagick_3.4.3~rc2-2_amd64.deb
Size: 93474
MD5sum: c0e5be16aded4e1a53e932003cf04d3d
SHA256: 2af644729fcb0c00b2b9696cfc67dbfb98aaf8503b6adeffb87d53a7b837d4e7

So apt seems to have know about this package, and as near as I can tell has no 
reason to claim that the package does not exist.

I guess there should be some sort debugging or verbose progress option here, 
for apt-get to report on whatever the issue is, here, which prevents it from 
seeing and installing this package. (Or at least a more informative error 
message than "no installation candidate"...)

Or, if the package matching logic is really that complex, that it's normal for 
it to fail this way, then that needs more user visibility (tracing tools, or 
whatever)?

-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-image";
APT::VersionedKernelPackages:: "linux-headers";
APT::VersionedKernelPackages:: "linux-image-extra";
APT::VersionedKernelPackages:: "linux-signed-image";
APT::VersionedKernelPackages:: "kfreebsd-image";
APT::VersionedKernelPackages:: "kfreebsd-headers";
APT::VersionedKernelPackages:: "gnumach-image";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::VersionedKernelPackages:: "linux-backports-modules-.*";
APT::VersionedKernelPackages:: "linux-tools";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "contrib/metapackages";
APT::Never-MarkAuto-Sections:: "non-free/metapackages";
APT::Never-MarkAuto-Sections:: "restricted/metapackages";
APT::Never-MarkAuto-Sections:: "universe/metapackages";
APT::Never-MarkAuto-Sections:: "multiverse/metapackages";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Move-Autobit-Sections:: "contrib/oldlibs";
APT::Move-Autobit-Sections:: "non-free/oldlibs";
APT::Move-Autobit-Sections:: "restricted/oldlibs";
APT::Move-Autobit-Sections:: "universe/oldlibs";
APT::Move-Autobit-Sections:: "multiverse/oldlibs";
APT::AutoRemove "";
APT::AutoRemove::SuggestsImportant "false";
APT::Update "";
APT::Update::Post-Invoke "";
APT::Update::Post-Invoke:: "rm -f /var/cache/apt/archives/*.deb 
/var/cache/apt/archives/partial/*.deb /var/cache/apt/*.bin || true";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Compressor "";
APT::Compressor::. "";
APT::Compressor::.::Name ".";
APT::Compressor::.::Extension "";
APT::Compressor::.::Binary "";
APT::Compressor::.::Cost "0";
APT::Compressor::lz4 "";
APT::Compressor::lz4::Name "lz4";
APT::Compressor::lz4::Extension ".lz4";
APT::Compressor::lz4::Binary "lz4";
APT::Compressor::lz4::Cost "50";
APT::Compressor::lz4::CompressArg "";
APT::Compressor::lz4::CompressArg:: "-1";
APT::Compressor::lz4::UncompressArg "";
APT::Compressor::lz4::UncompressArg:: "-d";
APT::Compressor::gzip "";
APT::Compressor::gzip::Name "gzip";
APT::Compressor::gzip::Extension ".gz";
APT::Compressor::gzip::Binary "gzip";
APT::Compressor::gzip::Cost "100";
APT::Compressor::gzip::CompressArg "";
APT::Compressor::gzip::CompressArg:: "-6n";
APT::Compressor::gzip::UncompressArg "";
APT::Compressor::gzip::UncompressArg:: "-d";
APT::Compressor::xz "";
APT::Compressor::xz::Name "xz";
APT::Compressor::xz::Extension ".xz";
APT::Compressor::xz::Binary "xz";
APT::Compressor::xz::Cost "200";
APT::Compressor::xz::Compr

Bug#342455: #342455

[Raul Miller]

On 2/10/06, Ian Jackson <[EMAIL PROTECTED]> channelled:
> The proposed change to devmapper changes the permissions for all block
> devices, doesn't it ?  Whereas the other debian defaults vary from one
> kind of device to another.  For example, floppies are g+w floppy.

The change to devmapper is inconsistent in the context of many groups
of machines.

It's also inconsistent over time on many single machines.

> For changing the `default' by changing the permissions at device
> creation time at the very least introduces a race, where the device
> briefly has the default permissions; if the defaults are maximally
> restrictive then this is OK.

The debian defaults grant permission to an empty group -- one
which by default has no users -- this is maximally restrictive.

--
Raul

Bug#342455: #342455

[Raul Miller]

On 2/10/06, Roger Leigh <[EMAIL PROTECTED]> wrote:
> I did read this, and I'm happy progress is being made.  However, the
> default is still currently wrong in unstable, and the fix is a simple
> change to configure in debian/rules.

I agree that the devmapper default should match other
debian defaults, and vice-versa.

And since I don't see any credible reasoning for changing
the defaults on other packages (especially for stable), I
think you're right that devmapper's default needs to be
changed.

If need be, we can issue this as a formal opinion.  (If I
don't hear any reasons why this would be a mistake, in
the next few days, I'll make this a formal proposal.)

Thanks,

--
Raul

Bug#342455: #342455

[Raul Miller]

On 2/10/06, Bastian Blank <[EMAIL PROTECTED]> wrote:
> On Fri, Feb 10, 2006 at 04:40:22PM -0800, Steve Langasek wrote:
> > Otherwise, having access to the underlying block devices means having access
> > to meddle with anything on the LVM devices as well.
>
> And who says that anyone have access to the underlying device?

The same person who says who has access to group disk.

--
Raul

Bug#342455: #342455

[Raul Miller]

On 2/10/06, Ian Jackson <[EMAIL PROTECTED]> wrote:
> Raul Miller writes ("Re: #342455"):
> > On 2/10/06, Ian Jackson <[EMAIL PROTECTED]> channelled:
> > > The proposed change to devmapper changes the permissions for all block
> > > devices, doesn't it ?  Whereas the other debian defaults vary from one
> > > kind of device to another.  For example, floppies are g+w floppy.
> >
> > The change to devmapper is inconsistent in the context of many groups
> > of machines.
>
> Um, are we talking about the same change here ?  I'm criticising the
> proposed change to the configure script which makes all the block
> devices start out g+w disk.

Yes, we're talking about the same change here.

If I have a cluster of debian machines (predating devmapper), by
default they'll all have block devices with g+w disk.

If I introduce devmapper systems into this cluster that will
not be true.

> > It's also inconsistent over time on many single machines.
>
> I agree that the current situation is unsatisfactory.  But I think (at
> the moment, at least) that it should be fixed by adopting Bastian's
> code fragments with an appropriate configuration.

I don't know what this means.

> > > For changing the `default' by changing the permissions at device
> > > creation time at the very least introduces a race, where the device
> > > briefly has the default permissions; if the defaults are maximally
> > > restrictive then this is OK.
> >
> > The debian defaults grant permission to an empty group -- one
> > which by default has no users -- this is maximally restrictive.
>
> This is rather disingenuous.  No-one would be complaining if the disk
> group remained empty.

That's demonstrably false: the disk group does remain empty on any
number of machines and people are complaining.  Even if the group is
not empty, access to the accounts which are members of that group
is under the control of the same person who gives access to root.

Last time I looked, when I created a new user account, I got a new
group with the same name which that user was a member of.  The
new accounts are not members of group disk.

Put differently: security is not about technology so much as it's
about the person who is responsible for the system understanding
what it's doing.  The details follow from the goals of the person
responsible for the system.

--
Raul

Bug#342455: #342455

[Raul Miller]

On 2/10/06, Steve Langasek <[EMAIL PROTECTED]> wrote:
> ... follow-up to self: given that crypt-dm sits on top of devmapper, it is
> indeed plausible that one would want to prevent members of group disk from
> reading the decrypted volume.

So don't use group disk in that context.

Just because a feature is available doesn't mean it has to be used.  Otherwise,
`chmod -R 777 /` would be a huge security hole.

--
Raul

Bug#353278: Bug#353277: ndiswrapper in main

[Raul Miller]

On 2/20/06, Robert Millan <[EMAIL PROTECTED]> wrote:
> I requested that ndiswrapper and ndiswrapper-modules-i386 be moved to contrib.

This proposal is clear enough.

> My reasons are:
>
>   - The sole purpose of these packages is allowing the use of non-free Windows
>   drivers.
>
>   - There are no free Windows drivers for this interface, except a port of a
>   Linux driver to Windows (cipe), which is only used on native Windows
>   platform (since it is pointless to emulate it from Linux, where the original
>   cipe is already available).

I'm not sure I agree with this.

When I look at the list of drivers that ndiswrapper supports
http://ndiswrapper.sourceforge.net/mediawiki/index.php/List
I see several that seem to be open source.

You've asserted that none of these drivers satisfy the DFSG,
but I think we would need more than an assertion on this issue.

As a specific counter example, consider
http://rt2x00.serialmonkey.com/wiki/index.php/Main_Page
which is a project porting a windows driver to linux.  This port
appears to be possible because the windows driver was made
available under a free license.

--
Raul

Bug#353277: ndiswrapper in main

[Raul Miller]

On 2/20/06, Anthony Towns  wrote:
> AFAICS, this would come under the "overrule a developer (3:1 majority)"
> power.

That's a good point.

While there are technical issues here (such as: "what software does ndiswrapper
depend on?"), they are not the deciding issues.   The core issues are more like
"how will most people use ndiswrapper"?

Focusing on the technical aspects is probably the wrong thing to do in
this case.

--
Raul

Bug#353277: ndiswrapper in main

[Raul Miller]

On 2/21/06, Margarita Manterola <[EMAIL PROTECTED]> wrote:
> On 2/20/06, Raul Miller <[EMAIL PROTECTED]> wrote:
> > As a specific counter example, consider
> > http://rt2x00.serialmonkey.com/wiki/index.php/Main_Page
> > which is a project porting a windows driver to linux.  This port
> > appears to be possible because the windows driver was made
> > available under a free license.
>
> With this particular driver, I think you are making a mistake.  rt2x00
> is available as an independent driver (i.e. without ndiswrapper).

What is my mistake?

It looks to me as if the sequence of events was:

1 "open source" windows driver available (can be used with ndiswrapper)
2 someone ports windows driver to linux
3 linux driver available

These events are sequential, and event 3 does not erase event 1.

> As can be read in the project's history [1], the open-source project
> started because Ralink decided to release the Linux drivers under a
> free license.  There's no mention on the page of a Windows driver.

So the mention is not on that particular page, and is on a different
page.  Why is this a problem?

Note: I'm not saying there is no problem.

But if we're going to change our rules for "acceptable in main" from
"FOO is allowed in main if FOO is free and everything FOO requires
for installation is free" to "FOO is allowed in main if the typical use of
FOO can does not involve any non-free software" then we have a
much bigger issue than ndiswrapper.

And if we're going to tackle this issue properly, we need to define
the problems clearly before we can even begin to come up with a
decent solution.

For example, while we might want to define a "six degrees of separation
free" debian subset, but before we could do that we'd need to have
a good idea of what goes in that subset, how people that use it can be
sure that that's what they're getting, what we're going to do about
people who have come to rely on other software, etc. etc.

--
Raul

Bug#353277: ndiswrapper in main

[Raul Miller]

On 2/21/06, Ian Jackson <[EMAIL PROTECTED]> wrote:
> Raul Miller writes ("Bug#353277: ndiswrapper in main"):
> > It looks to me as if the sequence of events was:
> >
> > 1 "open source" windows driver available (can be used with ndiswrapper)
> > 2 someone ports windows driver to linux
> > 3 linux driver available
> >
> > These events are sequential, and event 3 does not erase event 1.
>
> Was the open source windows driver ever available as a Debian
> package ?  It seems clear to me that anything which requires you to
> install non-Debian stuff on your machine belongs in contrib, even if
> the reason for the dependency being non-Debian is not non-freeness.

I don't believe it was ever available as a Debian package.

I'll also note that the "require" concept here gets interesting,
in this context,  as it's different from the concepts expressed in
our packaging system.

--
Raul

Bug#353277: ndiswrapper in main

[Raul Miller]

On 2/27/06, Margarita Manterola <[EMAIL PROTECTED]> wrote:
> On 2/21/06, Raul Miller <[EMAIL PROTECTED]> wrote:
> > 1 "open source" windows driver available (can be used with ndiswrapper)

> Well, I couldn't find any trace of "1" ever happening.  If it ever
> happened, then it's ok.  But as far as I know, the Ralink company went
> directly to 2 (porting there non-free windows driver to linux, and
> then making it free).  Can you provide any evidence that 1 ever
> happened?

You could be right.  I was going on second-hand evidence, and it
may very well be that the open source drivers that were being ported
were really linux drivers for other ralink hardware.

Note that we have a more general problem here -- we should not
have to find the answer to an open-ended question to determine
the suitability of a package for main.

If a package requires something else to be installed before it can be
used, we shouldn't have to figure out whether or not there exists a
suitable free version of that other software -- if it's not in main, we know
that this other software hasn't been packaged, and that should be
sufficient to push package which requires it be installed into contrib.

--
Raul

Bug#342455: Draft resolution on devmapper question

[Raul Miller]

On 4/3/06, Steve Langasek <[EMAIL PROTECTED]> wrote:
> Raul suggested in
>  that policy
> should also be amended to spell out the permissions for disk devices -- do
> we need to include text here which addresses that directly?

Perhaps the following item could be added to your draft (renumbering the
current item 14 as 15)

14. RECOMMENDS policy be updated to reflect this determination
on default block device permissions.

In general, your proposal looks good.

> (BTW, have people read Bastian's patches in
> ?  While
> they are a very encouraging development, if you look them over you'll see
> that Bastian has still implemented root:root 0600 as the default permissions
> for lvm2 -- so there is still an unresolved technical dispute here, not just
> an issue of time management...)

Yes.

Thanks,

--
Raul

Bug#345067: [Yaird-devel] Re: Processed: Escalating #345067 to the technical comittee, as the maintainer asked me to do so, and is unable or unwilling to do his job without this.

[Raul Miller]

On 3/7/06, Sven Luther <[EMAIL PROTECTED]> wrote:
> On Tue, Mar 07, 2006 at 07:20:31PM +0100, Jonas Smedegaard wrote:
> > Please see http://wiki.debian.org/LinuxKernelIdeProblem that I created
> > today and have invited the kernel team and udev developers to improve
> > on.
>
> An assembly of patent ...

It looks to me like that's a wiki page.

In other words, you can fix problems on it directly without needing to ask
for help or permission.  Though, obviously, including references to
supporting information will probably be a good thing in the context of
future changes.

I think posting corrections there might be a useful approach.

--
Raul

Bug#342455: #342455

[Raul Miller]

On 2/2/06, Roger Leigh <[EMAIL PROTECTED]> wrote:
> It's nearly a month since the last mail to this bug.  Is this getting
> close to being resolved?

Did you notice the content of the message before yours in this bug's
history?  It's from Bastian Blank, and includes among other things the
statement:

  I developed the idea for this fix some months ago, but never found the
  time to implement it. So I should have refrained from tagging the bugs
  wontfix.

It seems like there's no longer any technical dispute here, but perhaps
some time management issues to solve.

(If there's some technical dispute, we should be doing something about
that dispute, but if the dispute is resolved, we should be getting out
of the way so that you can get on with supporting your packages.)

Anyways, if Bastian doesn't have time, I think an NMU would
be appropriate.  Of course, if you can work with him so that
your potential NMU meshes with his intended fix that would be
even better.

Put differently: if things stand where I think they stand, we should
re-assign this bug to to package maintainer.  [But let us know if
you think we're overlooking something important.]

Thanks,

--
Raul

Bug#342455: Does anyone have anything more to say on the devmapper group/permissions issues?

[Raul Miller]

Is there anything more to be said about the devmapper group/permissions issues?

I've gone into this assuming that I've overlooked something important,
but so far I've not seen anything that makes me think that there's any
good reason for this conflict.

Does anyone have any credible reason why devmapper shouldn't use the
same defaults when creating a device as are used with other hard disk
devices?

Thanks,

--
Raul

Bug#342455: tech-ctte: Ownership and permissions of device mapper block devices

[Raul Miller]

On 12/23/05, Bastian Blank <[EMAIL PROTECTED]> wrote:
> Anyway, what are the problems with a default of 666? It fixes any
> of the problems.

Is this a serious question?

Access to group disk can be easily controlled by the
system administrator.  On some systems, only root
has this access, on other systems other ids also have
this access.  It's possible that all accounts will have
this access, but that's extremely rare.

That's not true for "other" -- everyone has access read
and write access to things with 666 permissions.

Do you need this explained further?

--
Raul

Bug#367709: requesting libstdc++ .udeb in order to produce c++ based images based on d-i technology (but not d-i).

[Raul Miller]

I'm not sure what you're asking.

Ideally, I'd like to see three things:

(1) A concise description of the technical conflict that needs to be resolved.

(2) Good background material for understanding any subtle issues
underlying the conflict.

(3) A concise, specific and unambiguous proposal for dealing with the conflict.

It looks to me as if you've put quite a lot of effort into (2).
However, I'm not at all certain I know what obstacle you are running
into, and I've some uncertainties about what you are proposing.

Have you talked to the di people about this issue?  Have they raised
any objections?  If so, what are they?  (We should get involved if you
feel that they are making a choice which is technically incorrect and
which you can't resolve directly.)

Thanks,

--
Raul

Bug#310994: ITP: openttd -- open source clone of the Microprose game "Transport Tycoon Deluxe"

[Raul Miller]

On 5/27/05, Michael K. Edwards <[EMAIL PROTECTED]> wrote:
> On 5/27/05, Matthijs Kooijman <[EMAIL PROTECTED]> wrote:
> > > That's correct; and, with or without that dependency, OpenTTD
> > > infringes the copyright on Transport Tycoon Deluxe under a "mise en
> > > scene" theory, as discussed on debian-legal.  (Not to say there's a
> > What do you mean by that exactly?
> 
> A video game with even the skimpiest of original story lines (see Duke
> Nukem 3-D, as described in Micro Star v. FormGen) is a "literary or
> artistic work" at run-time, over and above the expressive content of
> its source code.  Hence an additional form of "copyright infringement"
> is possible -- the creation of an unauthorized "sequel" using the
> original's characters and "mise en scene" (a term borrowed by lawyers
> from the theater; imagine the accent grave).

There's a difference between the kind of thing prohibited in the
Duke Nukem case and the kind of thing permitted in the Nintendo
case (Lewis Galoob Toys, Inc. v. Nintendo of America, Inc.).  In both 
cases, the "scene" changed.

In the Duke Nukem case, the additional scene elements were
"permanent" -- new scene elements were added to the game
data.

In the Nintendo case, the changed scene elements were 
"ephemeral" -- they only existed at execution time.

In my opinion (one M.K.Edwards does not share), OpenTTD is more like
the Nintendo case than the Duke Nukem case.  We're dealing with an
alternate game engine here (which is primarily functional in
character).  If you use the original game engine, at all, the
"changes" introduced by OpenTTD vanish.  In other words, these
changes appear to be ephemeral.

Since the court is treating these cases using concepts from theatre,
an analogy might be relevant:  The Nintendo case was analogous
to presenting the play on a different stage.  The Duke Nukem case
was analogous to presenting the play with a revised script.

-- 
Raul

Bug#14940: Can you still reproduce Debian bug 14940

[Raul Miller]

On 12/5/05, Nathanael Nerode <[EMAIL PROTECTED]> wrote:
> It's very old, Branden can't reproduce it, and if you the submitter can't,
> perhaps it should be closed.

I can't reproduce it.

Yeah, it should probably be closed.

Thanks,

--
Raul

Bug#342455: tech-ctte: Ownership and permissions of device mapper block devices

[Raul Miller]

I've been looking at these bugs, and I can see no good reason for the 600
permissions, nor the reason to avoid using the disk group.

There also seems to be some huge confusion about where responsibility for
setting permissions and group should be handled.

Here's what I currently see suggested:

1) change devmapper defaults -- patch rejected, no reason given
2) explicitly use udev -- problem, this doesn't work for 2.4 kernels
(2.4 used devfs)
3) avoid using devmapper (but this is not a solution)

I've also seen the suggestion that we should have a explicit technical policy
that block devices should default to having 660 permissions with owner root
and group disk.  I don't have any objections to such a policy, but I don't
see that solving this problem should wait on the adoption of this policy.

Finally, I don't see any reasoning given for things being the way they are
currently.  There might be some such reason, but I'm a bit dubious --
if there was a good reason, why wasn't it spelled out months ago?

Based on what I've seen so far, I'd recommend that the defaults for
devmapper be changed using Roger Leigh's 7 Dec patch from the
329409 bug report be adopted, that Bdale Garbee's 19 Nov patch
from the same bug report be adopted, and that policy be changed
to specify the default group and permissions for disk devices.

And, yes, that's overkill and in that sense inelegant.  But system stability
and predictability is a higher priority than "do it once and only once".
With differing kernel and package versions, we have to allow at least
for transition times when the same issues are dealt with in different
packages.  (And, yes, all of this should be spelled out in detail in
some package -- preferably the package where the final responsibility
resides).

I'm hoping someone can tell me what I've overlooked -- what is so
important here that's prevented this issue from being resolved?

Thanks,

--
Raul

Bug#342455: tech-ctte: Ownership and permissions of device mapper block devices

[Raul Miller]

On 12/16/05, Bastian Blank <[EMAIL PROTECTED]> wrote:
> On Wed, Dec 14, 2005 at 01:54:45PM +, Ian Jackson wrote:
> > Are you saying that the current default permissions on (eg) /dev/hda*
> > are insecure and therefore wrong ?
>
> Yes, I overwrite them on my machines.

And what is your reason for being unwilling to use the same procedure
on devmapper disks?

Do you believe that debian should deliver a patchwork collection of
administrative decisions, such that every time a new package is
installed a new set of administrative policies must be learned and
new procedures must be adopted by the users?

Personally, I'm using a system where the only way to obtain root access
is to log in as root -- there's no privileges gained through suid binaries.
Perhaps you'd like to use some significant packages configured this way
since it fixes something I consider to be a security problem?

Note also that your inconsistency is an inconsistency.  You've not
fixed the "problem" in all packages, only one package.  You've not
proposed anything to the community in general which addresses this
issue.  Instead, you've created problems for people without really
improving the security of debian systems in general.

This is a good idea?

Why?

What good thing have you accomplished?

Thanks,

--
Raul

Bug#342455: tech-ctte: Ownership and permissions of device mapper block devices

[Raul Miller]

On 12/17/05, Bastian Blank <[EMAIL PROTECTED]> wrote:
> On Fri, Dec 16, 2005 at 02:43:29PM -0500, Raul Miller wrote:
> > On 12/16/05, Bastian Blank <[EMAIL PROTECTED]> wrote:
> > > On Wed, Dec 14, 2005 at 01:54:45PM +, Ian Jackson wrote:
> > > > Are you saying that the current default permissions on (eg) /dev/hda*
> > > > are insecure and therefore wrong ?
> > >
> > > Yes, I overwrite them on my machines.
> >
> > And what is your reason for being unwilling to use the same procedure
> > on devmapper disks?
>
> Which procedure? You seem to know something I don't know. ("Overwrite"
> means in my context: chmod of static devices or a MODE setting in the
> udev config)

I'm trying to ask why you are unwilling to have devmapper disks provide
a default of root.disk 660?  Why can't you allow that to be the default?

Is there some reason you can't have implement your personally preferred
policy of root.root 600 on just your own system?  Is there some reason
for projecting your personal policies incompletely onto an arbitrary
subset of debian's users?

Is there something about this question I'm asking which doesn't make
sense to you?

> > Personally, I'm using a system where the only way to obtain root access
> > is to log in as root -- there's no privileges gained through suid binaries.
>
> Err? Write access to the device of a mounted filesystem is a way to gain
> root if you don't disable several options.

Quite a bit of stuff doesn't work the way you might normally expect, on that
particular system.

Anyways, good security means that the system works the way the person
responsible for the system think it's supposed to be working.

What you've done here introduces surprises and thus would tend to
degrade the security of debian users's systems (not directly but by
requiring that some people introduce ad-hoc and perhaps ill-considered
workarounds).

You seem to be asserting: "a malicious person who handles backups could
use the disk group to obtain root access, so you should force backup programs
to run as root."  But that does not seem to be a reasonable position:

(1) There are risks other than a malicious people -- by ensuring backup programs
don't have to run as root, we minimize the risks that such programs will do
something they weren't designed to do.

(2) A malicious person with physical access to the system can compromise
it in a variety of ways (boot with init=/bin/sh, replace the OS, add monitoring
hardware to the keyboard or the display, put a logic sniffer on the bus, etc.
etc.)

As things currently stand:

(A) The risk you're protecting against is not defeated by the measures
you propose.

(B) The measures you propose have not been accepted (or even discussed)
in the debian community at large.

(C) You've defeated some measures which make debian systems more
robust.

(D) You've clearly stated that you do not require that devmapper use these
defaults to implement your security policy.

I don't have any right to object to how you maintain your own personal systems,
but what you're inflicting on debian as a whole does not seem to make much
sense.

--
Raul

Bug#323035: Processed: referring issue to technical committee

[Raul Miller]

On 8/30/05, Robert McQueen <[EMAIL PROTECTED]> wrote:
> Raul Miller wrote:
> > It's not clear to me why this was assigned to the technical committee.

> The problem is that the maintainer refuses to concede that his packages
> are in violation of Debian's shared library packaging policy, or
> believes that this policy is incorrect or somehow irrelevant to his package.

That's definitely a problem, but it's not a technical problem.

> I was hoping that the technical committee might be able to discern which
> of these is the case, and then decide which elements need to be fixed
> and by whom, in order that the adoption of SILC-based software may
> continue in Debian.

If you had posed this as a technical question, we might have been able to
do something, but:

> However, it now seems that he's willing for someone else to maintain the
> package (see his mail on #273871), so it might be in order to orphan the
> package and close this technical committee bug.

You're probably right that it's best to simply close this bug.

Would you like to do the honors?

Thanks,

-- 
Raul

Bug#304350: Always ask for root passowrd twice, even on critical priority installs?

[Raul Miller]

On 6/9/05, Christian Perrier <[EMAIL PROTECTED]> wrote:
> Some people have argued this does against all established practices in
> such matter. Others have argued that the way to install a system is a
> very specific way and that, after all, the password confirmation is
> not *mandatory* to have the process continuing.
> 
> As the arguments seems quite solid both ways, I take the hard way and
> hereby ask about Your Wise Advice. The discussion inside the D-I team
> did not yield to a very strong advice, too, as far as I have analysed.

I must admit that I don't understand the argument for asking only once.

Could someone spell out those reasons for me?

I mean, I understand that implementing "ask only once" is slightly
simpler.  But but given that there's we're talking about a password
prompt, which provides the user no feedback (thus preventing
the usual mechanism for detecting keyboarding problems), this
doesn't seem to me to be a good idea.

If the point is that there's some other interface involved here -- 
where we're not really talking about a prompt but about a 
machine interface -- I could see a "only prompt once" policy
making sense.

Anyways, if someone could spell out these arguments a bit
further it would help a lot.

Thanks,

-- 
Raul

Bug#304350: Always ask for root passowrd twice, even on critical priority installs?

[Raul Miller]

On 6/12/05, Christian Perrier <[EMAIL PROTECTED]> wrote:
> Honestly, I'm having hard times to make my own mind and I need help
> and "wise" advice on that issue. I personnally tend to favor the
> current choice of only one prompt, but this is definitely not a strong
> position.

Is this true even after the comments offered by Manoj and Stephen?

If so, here's another way to look at this issue:  It's a problem in the
prompting facilities used by debconf.

In principle whenever debconf prompts a user for type "password",
it should prompt twice (in other words, any prompting facility 
which treats "password" different from "string" should have been
required to ask twice).  What we're thinking you should be doing 
here is working around a flaw in the architecture of debconf where 
this doesn't happen automatically.

Since you're using debonf you're stuck with this issue, at least
for now.  [And, unfortunately, changing this aspect of its 
architecture might be rather annoying.]

-- 
Raul

Bug#323035: repeate of notes

[Raul Miller]

This is a copy of the text I included on the re-assign message.  I'm
re-posting it so that it's more visible.

Note that my proposed solution for libsilc will almost certainly require
the use of epoch, and the present naming and numbering scheme
for libsilc is not very useful.

=

The policy posted in the initial post in this thread seems to be relevant.
The problem with the soversion seems to be real.  I don't see anyone
saying otherwise.  When I install libsilc, I see /usr/lib/libsilc-1.0.so.2.1.0, 
(as is reported in this bug report).

The mechanism suggested by Steve Langasek for extracting the
version information from the binary using objdump -p seems to be 
correct, though of course the naming he uses to prefix it is just
a suggestion.

The disagreement with this is a statment attributed to Toma 
"I won't follow this policy".  No technical reasoning is given.

His suggestion -- that every developer should compile his/her
code against the current up-to-date libsilc -- is that every user
of libsilc who doesn't have the most current unstable version
installed should expect to have libsilc be broken.

This is a grave problem.  But it doesn't seem to be a technical
problem.  If we have a developer who refuses to follow policy,
without giving any good technical reasons for doing so, that's 
really a matter for debian as a whole.

If, as reported, the developer is willing to let someone else take
over the package, I think that's what should be done.  If no one
else takes over this package and releases a fixed version before 
midnight september 10, 2005 (GMT), I'll release a fixed version
myself, and close this bug.  (I'd do it sooner, but I've got other 
things I need to deal with before then.)  

I'll follow up here if I uncover any other issues.

Thanks,

-- 
Raul

Bug#323035: Fix delayed...

[Raul Miller]

I think I have a working fix for this bug.  However, the disk with my
secret key on it is bad, so I can't upload at the moment.  I'll try to
address this monday evening.

For now, here's my approach. 

(A) In debian/rules change the build target, inserting the following just
before touch build-stamp:
# get proper name for shlib packages
$(CURDIR)/debian/control.sh $(CURDIR)/debian/control $(CURDIR)/lib/.libs

(B) The body of debian/control.sh is appended at the bottom of this
message.

I believe this will allow this bug to be closed.  (If not, I've overlooked
something important in these messages.)

-- 
Raul

#!/bin/sh
#
# bring debian/control up to date with the current library soname

# Note: libsilc should always consist of a single word
# if it's something else, something has been drastically
# changed and it's time to re-think this script
libsilc=$(
objdump -p $2/lib*so* |
awk '/SONAME/{print $2}' |
sed -e 's/\([0-9]\)\.so\./\1-/; s/\.so\.//; s/client//' |
sort -u
)

cat <<___ >$1.tmp
Source: silc-toolkit
Priority: optional
Maintainer: Tamas SZERB <[EMAIL PROTECTED]>
Section: devel
Build-Depends: debhelper (>= 4.0.0), autotools-dev
Standards-Version: 3.6.0

Package: $libsilc-dev
Section: libdevel
Architecture: any
Depends: $libsilc (= \${Source-Version})
Provides: libsilc-dev
Replaces: libsilc-dev
Conflicts: libsilc-dev
Description: developer files for SILC library (silc-toolkit)
  silc-toolkit developer files
 .
  SILC Project develops the Secure Internet Live Conferencing protocol (SILC),
 which is designed to provide most rich featured conferencing services and
 high security.

Package: $libsilc
Section: libs
Architecture: any
Depends: \${shlibs:Depends}, \${misc:Depends}
Provides: libsilc
Replaces: libsilc
Conflicts: libsilc
Description: SILC library (silc-toolkit)
  silc-toolkit library files
 .
Package: $libsilc
Section: libs
Architecture: any
Depends: \${shlibs:Depends}, \${misc:Depends}
Provides: libsilc
Replaces: libsilc
Conflicts: libsilc
Description: SILC library (silc-toolkit)
  silc-toolkit library files
 .
  SILC Project develops the Secure Internet Live Conferencing protocol (SILC),
 which is designed to provide most rich featured conferencing services and
 high security.

___

if diff $1.tmp $1; then
# preserve file modification timestamp on control
rm $1.tmp
else
# update control with recent changes
mv $1.tmp $1
fi

Bug#323035: Processed: referring issue to technical committee

[Raul Miller]

On 8/14/05, Debian Bug Tracking System <[EMAIL PROTECTED]> wrote:
> > reassign -1 tech-ctte
> Bug#323035: libslc violates library policies
> Bug reassigned from package `libsilc' to `tech-ctte'.

It's not clear to me why this was assigned to the technical committee.

There's definitely some issues here.  For example, it sounds like libsilc
has some bugs that need to be fixed.

But is there any problem that the technical committee needs to decide on?

If so, could someone clearly and simply state what this problem is?

Thanks,

-- 
Raul

Bug#385115: Sorry, no more RC bugs for non-free data in main (was: Bug#385115: chromium-data: Unclear license for some files)

[Raul Miller]

On 8/30/06, Roberto Gordo Saez <[EMAIL PROTECTED]> wrote:

I strongly disagree with your arguments. It looks that we have
opposite way of thinking, so I will not reply to them, it is going to
nowhere. Don't worry, as I said, I won't continue searching for this.


When conversations go nowhere, it's often because people are
not understanding what the other is saying.

In this case, I see one rather obvious issue (there may be others):

Steve Langasek has said, in essence

"When A says X, and we have no evidence to the contrary,
we believe A".

Your objection, in essence seems to be

"We should not believe X when we have no evidence that X
is true."

It seems to me that both of these statements are reasonable,
and that neither refutes the other.

This could turn into a "standards of evidence" discussion, but it
currently does not taste like that.

--
Raul


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#381162: cipe is getting stale

[Raul Miller]

Package: wnpp

There's a bug more than a year old about a new upstream
version available for cipe, with no discussion from the maintainer
as to why this new version has not been incorporated.  The
package should probably be orphaned, so that someone who
is more interested can maintain the package:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=264114

Also note that the last change to this package was in 2004,
and that there is a 4 year old important bug which has been
filed against the package, which has not been addressed
by the current maintainer, except to list it in a set of
confirmed reports.

--
Raul


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#383481: Must source code be easy to understand to fall under DFSG?

[Raul Miller]

On 10/31/06, Goswin von Brederlow <[EMAIL PROTECTED]> wrote:

* Person C creates a driver knowing with properly names defines and
comments explaining why he does what and where to easily readable
structures of the register mappings of the hardware. Person C then
goes and obfuscates the code into putting seemingly random values into
seemingly random addresses. Person C still uses his unobfuscated code
to makes changes but only releases the obfuscated version under GPL.


Note that the actions described could have a different intent
behind them:  backwards compatibility with older hardware.

More generally, backwards compatibility might look like
obfuscation, to people who are not familiar with the older
systems.  [It tends to be a case of "there's something
going on here which does not make sense."]

--
Raul


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#413926: wordpress: Should not ship with Etch

[Raul Miller]

On 3/12/07, Steve Langasek <[EMAIL PROTECTED]> wrote:

Hmm -- if it's the RMs' call, I guess that means Andi and I both are
required to abstain from any vote on this (Constitution 6.3.2).  Is it still
ok for me to call for a vote? :)  (FWIW, as RM the decision I consider to
have made is "defer to the judgement of the security team", so I guess the
TC does have a choice on who to overrule...)


I can think of no reason [constitutional or otherwise] why you should not be
allowed to call for a vote for the rest of the committee to
[potentially] override
you.

--
Raul


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#413926: Results of technical committee vote

[Raul Miller]

I apologize for not voting, but while I generally concur with
the voted decision, I have not had time to study any of
our issues in any depth these last couple weeks.

Thanks,

--
Raul


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]