Hello
> How is the effort going
> (http://lists.debian.org/debian-devel/2005/09/msg01362.html)?
Pity I've read about this only now :(
Making support for such additional 'archs', targeting mainly uclibc archs,
is *the* direction where I was going to move with dpkg-cross and debian
cross-toolcha
On 10/26/05, Nikita V. Youshchenko <[EMAIL PROTECTED]> wrote:
> Making support for such additional 'archs', targeting mainly uclibc archs,
> is *the* direction where I was going to move with dpkg-cross and debian
> cross-toolchain (I'm the current maintainer of those).
This is also a way we're cu
* Florian Weimer <[EMAIL PROTECTED]> [051025 13:51]:
> * Steve Langasek:
>
> > Frank Lichtenheld has already posted an announcement[4] detailing the
> > release team's plans for the question of non-DFSG documentation in main.
>
> Just to clarify, is technical documentation that is only available
On Wednesday 26 October 2005 03:57, Adam Heath wrote:
> Edit /etc/adduser.conf.
When you do a new installation, cron and exim (and possibly others) already
grabbed a gid before you can edit adduser.conf. Which leads to some annoying
manual tweaking if you need these gids otherwise.
Greetings
B
It seems that recently, the uncompressed version of the "Packages" file
has disappeared from the "unstable" archive on the Debian network
servers and all their mirrors.
http://ftp.debian.org/debian/dists/unstable/main/binary-i386/
On the other hand, the uncompressed file is still available for th
On Wed, Oct 26, 2005 at 08:18:42AM +0200, Marc Haber wrote:
> On Tue, 25 Oct 2005 22:21:18 +0200, Javier Fernández-Sanguino Peña
> <[EMAIL PROTECTED]> wrote:
> >Creating system users needs to cope with the fact that users might have
> >greated them before hand.
>
> adduser copes with that. If a sy
Le mardi 25 octobre 2005 à 15:09 -0200, Andre Filipe de Assuncao e Brito
a écrit :
> Package: wnpp
> Severity: wishlist
> Owner: Andre Filipe de Assuncao e Brito <[EMAIL PROTECTED]>
>
> * Package name: icon-naming-utils
> Version : 0.3.2
> Upstream Authors : Rodney Dawes <[EMAIL PR
On Wed, 26 Oct 2005 21:32, Ian Bruce wrote:
> It seems that recently, the uncompressed version of the "Packages" file
> has disappeared from the "unstable" archive on the Debian network
> servers and all their mirrors.
>
> http://ftp.debian.org/debian/dists/unstable/main/binary-i386/
>
> On the oth
Ian Bruce <[EMAIL PROTECTED]> writes:
> Some related questions:
>
> -- what is the purpose of the "Packages.diff/" directory which has
> appeared in the "testing" and "unstable" archives? Is there some piece
> of software which makes use of this for updating the packages lists?
apt-get (experimen
On Wed, 26 Oct 2005 11:11:00 +0200, Javier Fernández-Sanguino Peña
<[EMAIL PROTECTED]> wrote:
>On Wed, Oct 26, 2005 at 08:18:42AM +0200, Marc Haber wrote:
>> Thus, in most cases, a single call to adduser is all that's needed to
>> create a system user in postinst.
>
>I have yet to see a package th
On Tue, Oct 25, 2005 at 07:15:29PM +0200, Kurt Roeckx wrote:
> Then I guess it's either not used properly most of the time,
> or hard they make it hard to use it properly.
That's right. Requres.private: is supported only since pkg-config-0.18,
and there are not many packages making use of it yet.
On Wed, Oct 26, 2005 at 11:11:00AM +0200, Javier Fernández-Sanguino Peńa wrote:
> That really depends on the daemon itself don't you think? There's a number of
> daemons that don't create any file at all or, if they do, are created
> only on a given directory which is removed on purge. In these ca
On 10/26/05, Gabor Gombas <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 26, 2005 at 11:11:00AM +0200, Javier Fernández-Sanguino Peńa
> wrote:
>
> > That really depends on the daemon itself don't you think? There's a number
> > of
> > daemons that don't create any file at all or, if they do, are create
On Tue, Oct 25, 2005 at 12:02:16PM -0700, Thomas Bushnell BSG wrote:
> How does the ping package know which kernel I have installed?
That's the important thing: building of the package _must not_ depend on
the version of the installed kernel. If the kernel interface changes
from one kernel vers
On Wed, Oct 26, 2005 at 02:00:17PM +0200, Olaf van der Spek wrote:
> Removing the user is 'fine', it's the reusing that's the issue. But
> isn't that your own fault if you choose to reuse numbers?
If a package's postrm removes the user, and the next package's postinst
just calls "adduser", then t
On Wed, Oct 26, 2005 at 02:15:41PM +0200, Gabor Gombas wrote:
> If a package's postrm removes the user, and the next package's postinst
> just calls "adduser", then the admin have no control over the reusing.
>
> If you want to allow automatic user/group removal, then adduser should
> be extended
On Wed, 26 Oct 2005 12:05:08 +0200
Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
> > -- has there been any progress towards providing zsync access to the
> > archives? It would seem that this would result in greatly reduced
> > data traffic on the network servers, without increasing the
> > comp
On Wed, Oct 26, 2005 at 08:20:02AM -0400, sean finney wrote:
> On Wed, Oct 26, 2005 at 02:15:41PM +0200, Gabor Gombas wrote:
> > If a package's postrm removes the user, and the next package's postinst
> > just calls "adduser", then the admin have no control over the reusing.
> > If you want to all
Hi,
Gabor Gombas wrote:
And that means the
package must be built with the headers from the latest kernel version it
is designed to support.
In fact, it should be built against all versions of the kernel headers
it is supposed to support. If that causes difficulties, upstream
deserves to be
hey steve,
On Wed, Oct 26, 2005 at 05:29:46AM -0700, Steve Langasek wrote:
> In the general case, I can think of two reasons to remove users (but
> leave the ids reserved): namespace pollution, and user lookup performance
> when using flatfile /etc/passwd. Neither of these is particularly relevan
Guys:
Regarding this:
http://lists.debian.org/debian-devel/2005/09/msg01362.html
I would be very interested in mips and arm-el ports. I have dedicated
build hardware available for both. PLEASE let me know what else I can
do to help!
(I've tinkered with dpkg in the past, but I'm no guru.
On Wed, 26 Oct 2005, Ian Bruce wrote:
> option was implemented. Perhaps it's thought that more testing is
> required before it can be used for the archives; is there any other
> reason not to use it?
The way gzip --rsyncable works is perfectly safe, it cannot cause data loss
AFAIK. It just makes
* Marc Haber ([EMAIL PROTECTED]) wrote:
> On Wed, 26 Oct 2005 11:11:00 +0200, Javier Fernández-Sanguino Peña
> <[EMAIL PROTECTED]> wrote:
> > Some remove the user
> >(and fail to check if it was created by the postinst/preinst and not by the
> >alocal admin),
>
> Removing the user is a general bug
On Wed, Oct 26, 2005 at 12:16:43PM +0200, Marc Haber wrote:
> On Wed, 26 Oct 2005 11:11:00 +0200, Javier Fernández-Sanguino Peña
> <[EMAIL PROTECTED]> wrote:
> >Please explain, the code only changes /etc/{passwd,shadow,group}. Where's the
> >RC bug?
>
> If I generate user foo and give it some attr
On Monday 10 October 2005 01:11, "Marco d'Itri" <[EMAIL PROTECTED]> wrote:
> > Also the udev script is rather complex. It seems to me that a better
> > option might be to have the /etc/init.d/udev script call a udev setup
> > script (maybe named /sbin/setup_udev) and then start the udevd.
>
> I to
Hi,
I'd like to keep the files in the "Project Home Page" area of alioth in
our SVN repository, and I'm looking for a way to automate the updating
of these pages.
Ideally, we would use some post-commit hook that causes the changed html
file to be uploaded from svn.debian.org to alioth.debian.org,
On Wed, Oct 26, 2005 at 01:53:19PM +0200, Gabor Gombas wrote:
> On Wed, Oct 26, 2005 at 11:11:00AM +0200, Javier Fernández-Sanguino Pe?a
> wrote:
>
> > That really depends on the daemon itself don't you think? There's a number
> > of
> > daemons that don't create any file at all or, if they do,
Frank Küster wrote:
- how to write the hook so that only specific files are uploaded, and
put into the right location
- how to authenticate the transfer, since the svn repository and the
webspace is on different machines.
Has anybody already set up something like this?
Only on the s
On Wed, Oct 26, 2005 at 03:38:08PM +0200, Frank Küster wrote:
> I'd like to keep the files in the "Project Home Page" area of alioth in
> our SVN repository, and I'm looking for a way to automate the updating
> of these pages.
I've done if for a number of projects (like buffy). You can have a lo
Javier Fernández-Sanguino Peña <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 26, 2005 at 01:53:19PM +0200, Gabor Gombas wrote:
>> On Wed, Oct 26, 2005 at 11:11:00AM +0200, Javier Fernández-Sanguino Pe?a
>> wrote:
>>
>> > That really depends on the daemon itself don't you think? There's a number
>> >
On Wed, Oct 26, 2005 at 03:50:36PM +0200, Javier Fernández-Sanguino Peńa wrote:
> Wrong. That is only true in the chown() case. Which is not a sensible thing
> to do. Daemons should be able to read their configuration files but they
> usually *don't* need to *write* them, so they should *not* own
* sean finney ([EMAIL PROTECTED]) [051026 14:20]:
> On Wed, Oct 26, 2005 at 02:15:41PM +0200, Gabor Gombas wrote:
> > If a package's postrm removes the user, and the next package's postinst
> > just calls "adduser", then the admin have no control over the reusing.
> >
> > If you want to allow auto
Javier Fernández-Sanguino Peña <[EMAIL PROTECTED]> writes:
>> Removing system users on package purge is widely regarded a bug since
>> one cannot guarantee that the local admin hasn't used the account for
>> other things as well. Additionally, removing the system user on
>> package purge might lea
Gabor Gombas <[EMAIL PROTECTED]> writes:
> IMHO you can safely remove an user/group _only_ if you have made sure
> there are no files owned by that uid/group left on any filesystems (and
> checking that may be tricky if the system uses ACLs, for example).
"Any filesystems" here must include remov
On Wed, Oct 26, 2005 at 05:24:28PM +0200, Frank Küster wrote:
> Javier Fernández-Sanguino Peña <[EMAIL PROTECTED]> wrote:
>
> > On Wed, Oct 26, 2005 at 01:53:19PM +0200, Gabor Gombas wrote:
> >> On Wed, Oct 26, 2005 at 11:11:00AM +0200, Javier Fernández-Sanguino Pe?a
> >> wrote:
> >>
> >> > That
Stephen Frost <[EMAIL PROTECTED]> writes:
> I disagree with the idea that removing a user is a bug. If the user was
> added by the package, and the package is being purged, and there's a
> reasonable expectation that it wasn't used outside of the package's use
> of it then I think it's probably s
Em Qua, 2005-10-26 às 11:31 +0400, Wartan Hachaturow escreveu:
> On 10/26/05, Nikita V. Youshchenko <[EMAIL PROTECTED]> wrote:
> > Making support for such additional 'archs', targeting mainly uclibc archs,
> > is *the* direction where I was going to move with dpkg-cross and debian
> > cross-toolcha
Em Qua, 2005-10-26 às 07:40 -0500, Bill Gatliff escreveu:
> I would be very interested in mips and arm-el ports. I have dedicated
> build hardware available for both. PLEASE let me know what else I can
> do to help!
Well I do think i386-uclibc will help another subarches, like arm-uclibc
armeb
Em Qua, 2005-10-26 às 16:43 +1300, Alex King escreveu:
> How is the effort going
> (http://lists.debian.org/debian-devel/2005/09/msg01362.html)?
Please see the other posts I made in this thread for more info. I just
wanted to point that I'm almost all the time (when working on this) on
#debian-dev
Hi,
As you may know, I'm working on i386-uclibc arch. And I'm finally
starting to build the base+build-essential packages. At this moment I
have a list of 87 source packages (not counting these packages
build-dep) that must be built.
The question is: Is there a way (I mean, already implemented) t
On Wed, Oct 26, 2005 at 05:24:46PM +0200, Gabor Gombas wrote:
> On Wed, Oct 26, 2005 at 03:50:36PM +0200, Javier Fernández-Sanguino Pe?a
> wrote:
>
> > Wrong. That is only true in the chown() case. Which is not a sensible thing
> > to do. Daemons should be able to read their configuration files b
On Wed, Oct 26, 2005 at 05:39:45PM +0200, Andreas Barth wrote:
> > i don't think removing and reusing users is a good idea in practice.
> > what harm would there be in simply leaving the user account on the
> > system permenantly, with maybe locking the account and setting the
> > shell to /bin/fa
Package: wnpp
Severity: normal
Hi,
I cannot work on PyXMMS anymore and am hereby orphaning it.
Description: Python interface to XMMS
PyXMMS, packaged as python-xmms in Debian, is a set of Python bindings
for the libxmms library. With PyXMMS, you can control an XMMS session
and manage the XMM
Package: wnpp
Severity: normal
Hi,
I cannot work on PyXMMS-remote anymore and am hereby orphaning it.
Description: command-line interface to XMMS
PyXMMS-remote allows you to control (or start, or terminate) an XMMS
session from your shell's command-line (or a program, or a MIME-aware
applic
Package: wnpp
Severity: normal
Hi,
I cannot work on lmodern anymore and am hereby orphaning it.
Description: scalable PostScript fonts for european character sets
The Latin Modern fonts, also known as "lm fonts", are a set of
scalable fonts in PostScript Type 1 format. They are based on the
* Thomas Bushnell BSG ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
>
> > I disagree with the idea that removing a user is a bug. If the user was
> > added by the package, and the package is being purged, and there's a
> > reasonable expectation that it wasn't used outsid
* Andreas Barth ([EMAIL PROTECTED]) wrote:
> * sean finney ([EMAIL PROTECTED]) [051026 14:20]:
> > i don't think removing and reusing users is a good idea in practice.
> > what harm would there be in simply leaving the user account on the
> > system permenantly, with maybe locking the account and s
On Wed, Oct 26, 2005 at 08:44:12AM -0700, Thomas Bushnell BSG wrote:
>
> "One cannot guarantee that the local admin hasn't used the account for
> other things as well."
>
> Please read.
We cannot guarantee that an admin fiddles with binaries in /usr/bin/ (as
opposed to /usr/local/bin) either. Th
* Gabor Gombas ([EMAIL PROTECTED]) [051026 18:03]:
> On Wed, Oct 26, 2005 at 05:39:45PM +0200, Andreas Barth wrote:
>
> > > i don't think removing and reusing users is a good idea in practice.
> > > what harm would there be in simply leaving the user account on the
> > > system permenantly, with m
* Javier Fernández-Sanguino Peña ([EMAIL PROTECTED]) [051026 18:09]:
> "We can provide a sensible default for system users' removals that copes with
> most situations and leave a door open (through debconf) to sysadmins that
> want to fiddle with system users."
I really want to warn to try to be
Andreas Barth wrote:
* Javier Fernández-Sanguino Peña ([EMAIL PROTECTED]) [051026 18:09]:
"We can provide a sensible default for system users' removals that
copes with most situations and leave a door open (through debconf)
to sysadmins that want to fiddle with system users."
I really want to
* Humberto Massa ([EMAIL PROTECTED]) [051026 18:28]:
> Andreas Barth wrote:
> >* Javier Fernández-Sanguino Peña ([EMAIL PROTECTED]) [051026 18:09]:
> >>"We can provide a sensible default for system users' removals that
> >>copes with most situations and leave a door open (through debconf)
> >>to sy
Andreas Barth wrote:
* Humberto Massa ([EMAIL PROTECTED]) [051026 18:28]:
Andreas Barth wrote:
* Javier Fernández-Sanguino Peña ([EMAIL PROTECTED]) [051026 18:09]:
"We can provide a sensible default for system users' removals that
copes with most situations and leave a door open (through debco
* Humberto Massa ([EMAIL PROTECTED]) [051026 18:34]:
> in my workstation I try out a new package (for scientfic computing, a
> game for Lucas, a new development package) at least once each two days,
> and a lot of times they come with their libs and their daemons -- and
> their users. So I see t
Andreas Barth wrote:
* Humberto Massa ([EMAIL PROTECTED]) [051026 18:34]:
in my workstation I try out a new package (for scientfic computing, a
game for Lucas, a new development package) at least once each two days,
and a lot of times they come with their libs and their daemons -- and
their us
* Humberto Massa ([EMAIL PROTECTED]) [051026 18:48]:
> Andreas Barth wrote:
> >* Humberto Massa ([EMAIL PROTECTED]) [051026 18:34]:
> >>in my workstation I try out a new package (for scientfic computing, a
> >>game for Lucas, a new development package) at least once each two days,
> >>and a lot o
ke, 2005-10-26 kello 14:30 -0300, Humberto Massa kirjoitti:
> Problem being, if daemons don't remove their (supposedly exclusive-use)
> accounts, you can end in two years with 100 unnecessary accounts in a
> workstation.
It would certainly be good if we had a system for marking accounts as
unused
On Wed, Oct 26, 2005 at 05:11:00AM -0700, Ian Bruce wrote:
>
> If the .deb files were compressed using the gzip "--rsyncable" option,
> then fetching them with zsync (or rsync) would be considerably more
> efficient than straight HTTP transfers.
No it wouldn't. Remember that .deb files are never
Hello everyone,
following all the discussion about when to add or remove users/groups
and when to do this, i must that maybe some work is done (not using the
standard adduser commands but almost).
I package libuser (from RH). From the Description:
"The libuser library impl
Javier Fernández-Sanguino Peña <[EMAIL PROTECTED]> writes:
> On Wed, Oct 26, 2005 at 08:44:12AM -0700, Thomas Bushnell BSG wrote:
>>
>> "One cannot guarantee that the local admin hasn't used the account for
>> other things as well."
>>
>> Please read.
>
> We cannot guarantee that an admin fiddle
Humberto Massa <[EMAIL PROTECTED]> writes:
> Problem being, if daemons don't remove their (supposedly exclusive-use)
> accounts, you can end in two years with 100 unnecessary accounts in a
> workstation.
And what bad results does this produce?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with
Stephen Frost <[EMAIL PROTECTED]> writes:
> * Thomas Bushnell BSG ([EMAIL PROTECTED]) wrote:
>> Stephen Frost <[EMAIL PROTECTED]> writes:
>>
>> > I disagree with the idea that removing a user is a bug. If the user was
>> > added by the package, and the package is being purged, and there's a
>> >
* Thomas Bushnell BSG ([EMAIL PROTECTED]) wrote:
> Humberto Massa <[EMAIL PROTECTED]> writes:
>
> > Problem being, if daemons don't remove their (supposedly exclusive-use)
> > accounts, you can end in two years with 100 unnecessary accounts in a
> > workstation.
>
> And what bad results does this
* Thomas Bushnell BSG ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > By knowing what the package uses the user for. This is somewhat akin to
> > the PostgreSQL package's question "do you want your data files to be
> > purged upon package removal", or the fact that the d
> Today my packages with PEAR modules was rejected from incoming queue.
> The reason is that PHP License was used for PEAR library.
>
> I've found many packages already existing in Debian archive which are
> licensed with PHP License. What does it mean? Should I fill bug reports
> with critical se
Stephen Frost <[EMAIL PROTECTED]> writes:
> * Thomas Bushnell BSG ([EMAIL PROTECTED]) wrote:
>> Stephen Frost <[EMAIL PROTECTED]> writes:
>> > By knowing what the package uses the user for. This is somewhat akin to
>> > the PostgreSQL package's question "do you want your data files to be
>> > pur
* Thomas Bushnell BSG ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > Same way you know that the system administrator hasn't modified a file
> > in /usr/bin.
>
> Um, I know that by comparing the contents against a known-true
> version. How do I detect whether the system
* Stephen Frost ([EMAIL PROTECTED]) [051026 20:13]:
> * Thomas Bushnell BSG ([EMAIL PROTECTED]) wrote:
> > Stephen Frost <[EMAIL PROTECTED]> writes:
> > > Same way you know that the system administrator hasn't modified a file
> > > in /usr/bin.
> >
> > Um, I know that by comparing the contents aga
* Andreas Barth ([EMAIL PROTECTED]) wrote:
> * Stephen Frost ([EMAIL PROTECTED]) [051026 20:13]:
> > This is just patently false, as has been pointed out elsewhere. What
> > security hole, exactly, is created by orphaning a file?
>
> Well, if some process (maybe within the package) creates a priv
* Stephen Frost ([EMAIL PROTECTED]) [051026 20:46]:
> Additionally, this is *not* a problem with the orphaning of the file,
> it's a problem with the reuse of a previously-used uid. I could see
> adding a system to track previously-used uids and not reusing them. I
> don't believe using passwd fo
* Andreas Barth ([EMAIL PROTECTED]) wrote:
> * Stephen Frost ([EMAIL PROTECTED]) [051026 20:46]:
> > Additionally, this is *not* a problem with the orphaning of the file,
> > it's a problem with the reuse of a previously-used uid. I could see
> > adding a system to track previously-used uids and n
On Wed, Oct 26, 2005 at 02:58:15PM -0400, Stephen Frost wrote:
> Leaving around unused accounts is plainly wrong too, and also a
iyho.
> potential security risk. If we're going to try to push for a broad
> change in how this is handled then let's do it the *right* way by
or, how about we not pu
On Wed, 26 Oct 2005, Javier Fernández-Sanguino Peña wrote:
> On Wed, Oct 26, 2005 at 05:24:28PM +0200, Frank Küster wrote:
> > What about log files with sensitive content?
>
> Non-issue, as I said in the end of my post, those should be removed
> on purge.
The log files that are created by the def
* sean finney ([EMAIL PROTECTED]) wrote:
> On Wed, Oct 26, 2005 at 02:58:15PM -0400, Stephen Frost wrote:
> > Leaving around unused accounts is plainly wrong too, and also a
>
> iyho.
Duh? I ain't humble tho. :)
> > potential security risk. If we're going to try to push for a broad
> > change
* Don Armstrong ([EMAIL PROTECTED]) wrote:
> On Wed, 26 Oct 2005, Javier Fernández-Sanguino Peña wrote:
> > On Wed, Oct 26, 2005 at 05:24:28PM +0200, Frank Küster wrote:
> > > What about log files with sensitive content?
> >
> > Non-issue, as I said in the end of my post, those should be removed
>
Stephen Frost wrote:
* Andreas Barth ([EMAIL PROTECTED]) wrote:
* Stephen Frost ([EMAIL PROTECTED]) [051026 20:13]:
This is just patently false, as has been pointed out elsewhere.
What
security hole, exactly, is created by orphaning a file?
Well, if some process (maybe within the package) cr
* Stephen Frost ([EMAIL PROTECTED]) [051026 20:58]:
> Leaving around unused accounts is plainly wrong too, and also a
> potential security risk.
I'm certain you can proof this.
> If we're going to try to push for a broad
> change in how this is handled then let's do it the *right* way by
> creati
Stephen Frost <[EMAIL PROTECTED]> writes:
> * Thomas Bushnell BSG ([EMAIL PROTECTED]) wrote:
>> Stephen Frost <[EMAIL PROTECTED]> writes:
>> > Same way you know that the system administrator hasn't modified a file
>> > in /usr/bin.
>>
>> Um, I know that by comparing the contents against a known-t
In various discussions recently it has been suggested that it would be
a good idea (TM) to make the init.d scripts run in parallel. This involves
using some tags from the new LSB and generally making explicit some
run-time dependencies that have had to be hacked to assumed in the
past.
It occurs
Stephen Frost <[EMAIL PROTECTED]> writes:
> * Andreas Barth ([EMAIL PROTECTED]) wrote:
>> * Stephen Frost ([EMAIL PROTECTED]) [051026 20:13]:
>> > This is just patently false, as has been pointed out elsewhere. What
>> > security hole, exactly, is created by orphaning a file?
>>
>> Well, if some
Stephen Frost <[EMAIL PROTECTED]> writes:
> Leaving around unused accounts is plainly wrong too, and also a
> potential security risk.
Can you outline the risk please?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Stephen Frost <[EMAIL PROTECTED]> writes:
> Have we actually got a specific case of this happening and there being a
> real security threat from it? Seems like an aweful lot of hand-waving
> and concern for a possible scenario that doesn't seem to have actually
> happened much (if it all, so far
> I'm now working on discovering the best order to build the 87 needed
> source packages to get a base+buildessential set for debootstrap.
I believe this should be done on normal debian host, using dpkg-cross's
'dpkg-buildpackage -a'. As of it's current state, it won't work. But it
could be made t
David Goodenough <[EMAIL PROTECTED]> writes:
> In various discussions recently it has been suggested that it would be
> a good idea (TM) to make the init.d scripts run in parallel. This involves
> using some tags from the new LSB and generally making explicit some
> run-time dependencies that hav
* Thomas Bushnell BSG ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
>
> > Leaving around unused accounts is plainly wrong too, and also a
> > potential security risk.
>
> Can you outline the risk please?
Sure. Locking accounts isn't necessairly perfect. Checking that
ke, 2005-10-26 kello 12:39 -0700, Thomas Bushnell BSG kirjoitti:
> David Goodenough <[EMAIL PROTECTED]> writes:
>
> > In various discussions recently it has been suggested that it would be
> > a good idea (TM) to make the init.d scripts run in parallel. This involves
> > using some tags from the
* Thomas Bushnell BSG ([EMAIL PROTECTED]) wrote:
> We aren't talking about log files created by the package, but by the
> sysadmin.
>
> What if the sysadmin has taken the sensitive log and squirreled it
> away, saving it for future reference? Is that no longer a supported
> thing?
One would hop
* Lars Wirzenius ([EMAIL PROTECTED]) wrote:
> ke, 2005-10-26 kello 12:39 -0700, Thomas Bushnell BSG kirjoitti:
> > David Goodenough <[EMAIL PROTECTED]> writes:
> >
> > > In various discussions recently it has been suggested that it would be
> > > a good idea (TM) to make the init.d scripts run in
On Wed, Oct 26, 2005 at 06:29:57PM +0200, Andreas Barth wrote:
> > Problem being, if daemons don't remove their (supposedly exclusive-use)
> > accounts, you can end in two years with 100 unnecessary accounts in a
> > workstation.
>
> How many daemon packages do you install in two years? I even dou
Scripsit Thomas Bushnell BSG <[EMAIL PROTECTED]>
> David Goodenough <[EMAIL PROTECTED]> writes:
>> In various discussions recently it has been suggested that it would be
>> a good idea (TM) to make the init.d scripts run in parallel. This involves
>> using some tags from the new LSB and generally
This one time, at band camp, Javier Fernández-Sanguino Peña said:
> On Wed, Oct 26, 2005 at 08:18:42AM +0200, Marc Haber wrote:
> > On Tue, 25 Oct 2005 22:21:18 +0200, Javier Fernández-Sanguino Peña
> > <[EMAIL PROTECTED]> wrote:
> > >Creating system users needs to cope with the fact that users mig
On Wed, 26 Oct 2005 19:12:30 +0200
Kurt Roeckx <[EMAIL PROTECTED]> wrote:
> > If the .deb files were compressed using the gzip "--rsyncable"
> > option, then fetching them with zsync (or rsync) would be
> > considerably more efficient than straight HTTP transfers.
>
> No it wouldn't. Remember th
Stephen Frost <[EMAIL PROTECTED]> writes:
> * Thomas Bushnell BSG ([EMAIL PROTECTED]) wrote:
>> Stephen Frost <[EMAIL PROTECTED]> writes:
>>
>> > Leaving around unused accounts is plainly wrong too, and also a
>> > potential security risk.
>>
>> Can you outline the risk please?
>
> Sure. Lock
This one time, at band camp, Thomas Bushnell BSG said:
> Stephen Frost <[EMAIL PROTECTED]> writes:
>
> > * Thomas Bushnell BSG ([EMAIL PROTECTED]) wrote:
> >> Stephen Frost <[EMAIL PROTECTED]> writes:
> >>
> >> > Leaving around unused accounts is plainly wrong too, and also a
> >> > potential sec
Stephen Gran <[EMAIL PROTECTED]> writes:
> Many authentiaction systems do not use pam or shadow authentication.
> That's the point of the counter argument.
So how does removing the line from the password file suddenly change
things?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subj
On 10454 March 1977, Ian Bruce wrote:
> Returning to the original question: Does anybody know why the
> uncompressed "Packages" file has disappeared from the "unstable"
> archive?
Because relevant tools do not / should not use that file since years. It
was announced *long* ago "to be in a few day
On Wed, 26 Oct 2005, David Goodenough wrote:
> Does this make sense?
Yes, it does. Such functionality is part of a proper dependency-based
initscript system, actually. Which doesn't actually have much to do with
parallel execution (hint: you can do parallel execution with just the
regular orderi
On Wed, Oct 26, 2005 at 08:18:42AM +0200, Marc Haber wrote:
> On Tue, 25 Oct 2005 22:21:18 +0200, Javier Fernández-Sanguino Peña
> <[EMAIL PROTECTED]> wrote:
> >Creating system users needs to cope with the fact that users might
> >have greated them before hand.
> adduser copes with that. If a syste
This one time, at band camp, Thomas Bushnell BSG said:
> Stephen Gran <[EMAIL PROTECTED]> writes:
>
> > Many authentiaction systems do not use pam or shadow authentication.
> > That's the point of the counter argument.
>
> So how does removing the line from the password file suddenly change
> t
> "Javier" == Javier Fernández-Sanguino Peña <[EMAIL PROTECTED]> writes:
>> Thus, in most cases, a single call to adduser is all that's
>> needed to create a system user in postinst.
Javier> I have yet to see a package that "just" calls
Javier> adduser. Some remove the user (
1 - 100 of 107 matches
Mail list logo
