On 03/03/19 17:59, Kurt Roeckx wrote:
> I think the only sane things are:
> - Use a hardware RNG (CPU, TPM, chaos key, ...)
> - Credit a seed file stored during the previous boot
> - Wait for new entropy from other sources
>
> Note that is can be a combination of all 3.
>
> We currently do not
On Sun, 2019-03-03 at 22:55 +0100, Kurt Roeckx wrote:
> On Sun, Mar 03, 2019 at 08:19:44PM +, Ben Hutchings wrote:
> > On Sun, 2019-03-03 at 18:59 +0100, Kurt Roeckx wrote:
> > [...]
> > > Most people will actually have at least 2 hardware RNGs: One in
> > > the CPU and one in the TPM. We can
On Sun, Mar 03, 2019 at 08:19:44PM +, Ben Hutchings wrote:
> On Sun, 2019-03-03 at 18:59 +0100, Kurt Roeckx wrote:
> [...]
> > Most people will actually have at least 2 hardware RNGs: One in
> > the CPU and one in the TPM. We can make the kernel trust those as
> > entropy source without using
On Sun, 2019-03-03 at 18:59 +0100, Kurt Roeckx wrote:
[...]
> Most people will actually have at least 2 hardware RNGs: One in
> the CPU and one in the TPM. We can make the kernel trust those as
> entropy source without using something in userspace to feed it.
> I'm not sure in the kernel has the
I think the only sane things are:
- Use a hardware RNG (CPU, TPM, chaos key, ...)
- Credit a seed file stored during the previous boot
- Wait for new entropy from other sources
Note that is can be a combination of all 3.
We currently do not credit the seed file, for various good
reasons. We
]] Thorsten Glaser
> … this was not true for me. Not before init takes over, anyway (as
> haveged does not have any initramfs integration), but we’re talking
> about “crng init done” here, not “fast init done”. In my scenario,
> haveged was started much too late in the boot to be useful (after
>
> "Thorsten" == Thorsten Glaser writes:
Thorsten> It’s not about what we feed to the kernel, but about the
Thorsten> property of it distributing the input evenly across the
Thorsten> output. The basic tenet here is that, if I have 128 bytes
Thorsten> of random input from the
Ben Hutchings dixit:
>On Thu, 2019-02-28 at 14:52 +, Ian Jackson wrote:
>>Thorsten Glaser writes ("FYI/RFC: early-rng-init-tools"):
>>> • during postinst, creates a 128-byte random seed file in /
>>
>>Can you confirm that this is done with data from
&
Sebastian Andrzej Siewior dixit:
>so I have one older box that suffers from that. I installed haveged and
>seemed to went away:
I tried that, after the suggestion to use haveged went up, but…
>As far as I understand, it would reach the "init done" state before
>systemd took over, right?
… this
> "Ben" == Ben Hutchings writes:
>> If the seed > files used in two different boots are somewhat
>> correlated, and the > entropy estimation doesn't account for
>> that, the output of /dev/random > may also be somewhat correlated
>> between the boots, which is not > supposed
On Thu, 2019-02-28 at 14:52 +, Ian Jackson wrote:
[...]
> > to initialise a stretching RNG (arc4random)
>
> Why are you feeding this through a separate hashing function rather
> than letting the kernel PRNG's hasher do it ? I am seriously
> unconvinced that arc4random is a good idea
On Thu, 2019-02-28 at 11:56 +, Ian Jackson wrote:
> Ben Hutchings writes ("Re: FYI/RFC: early-rng-init-tools"):
> > On Mon, 2019-02-25 at 19:37 +0200, Uoti Urpala wrote:
> > > Generally you don't ever
> > > need to use /dev/random instead of /dev/urandom un
Thorsten Glaser writes ("FYI/RFC: early-rng-init-tools"):
> • during postinst, creates a 128-byte random seed file in /
Can you confirm that this is done with data from
getrandom(,,GRND_RANDOM) ? (Presumably with GRND_NONBLOCK too.)
> – after the root filesystem is read-writ
>>>>> "Ian" == Ian Jackson writes:
Ian> Sam Hartman writes ("Re: FYI/RFC: early-rng-init-tools"):
>> Ben Hutchings writes: >[Someone:] >> The
>> additional entropy gathered is for extra safety; it is
Ben Hutchings writes ("Re: FYI/RFC: early-rng-init-tools"):
> On Mon, 2019-02-25 at 19:37 +0200, Uoti Urpala wrote:
> > Generally you don't ever
> > need to use /dev/random instead of /dev/urandom unless you make
> > assumptions about cryptograph
Sam Hartman writes ("Re: FYI/RFC: early-rng-init-tools"):
> Ben Hutchings writes:
> >[Someone:]
> >> The additional entropy gathered is for extra safety; it is not
> >> *depended* on for basic security assumptions.
> > [...]
> It is, because t
> "Ben" == Ben Hutchings writes:
>> The additional entropy gathered is for extra safety; it is not
>> *depended* on for basic security assumptions.
Ben> [...]
Ben> It is, because the the kernel is told to treat it as providing
Ben> a certain number of bits of entropy.
I
On Tue, 2019-02-26 at 22:29 +0200, Uoti Urpala wrote:
> On Tue, 2019-02-26 at 19:10 +, Ben Hutchings wrote:
> > But if the input to the seed doesn't provide enough entropy, the seed
> > is not completely secret (that is, you can recover it with less work
> > than a brute force search). The
On Mon, 2019-02-25 at 14:36 -0500, Sam Hartman wrote:
> > > > > > "Ben" == Ben Hutchings writes:
>
> Ben> The output of the RNG may well become public, for example in
> Ben> document UUIDs. So when estimating the entropy that the new
> Ben> seed file will provide for the next boot,
> "Ben" == Ben Hutchings writes:
Ben> The output of the RNG may well become public, for example in
Ben> document UUIDs. So when estimating the entropy that the new
Ben> seed file will provide for the next boot, none of the entropy
Ben> in the old seed file should be
On 2019-02-24 19:52:59 [+], Thorsten Glaser wrote:
> tl;dr: it adds entropy during initramfs/as early as possible during
> boot *and* tells the kernel it did so, to make its crng initialised,
> and ensures a subsequent boot has a different seed, also updated
> periodically and on shutdown for
On Mon, 2019-02-25 at 19:37 +0200, Uoti Urpala wrote:
[...]
> Generally you don't ever
> need to use /dev/random instead of /dev/urandom unless you make
> assumptions about cryptography failing.
[...]
I think I agree with that, but there is no way to add entropy that
unblocks getrandom() without
On Mon, 2019-02-25 at 16:48 +, Thorsten Glaser wrote:
> Ben Hutchings dixit:
>
> >> ‣ writes between 32 and 256 bytes to /dev/urandom (but does not
> >> accredit them yet, just remembers the amount written)
> >
> >How do you determine the number of bytes here?
>
> 32 +
Ben Hutchings dixit:
>> ‣ writes between 32 and 256 bytes to /dev/urandom (but does not
>> accredit them yet, just remembers the amount written)
>
>How do you determine the number of bytes here?
32 + arc4random_uniform(256 - 32 + 1)
[…]
>The major input into the new seed file contents
On Mon, 2019-02-25 at 18:27 +0200, Uoti Urpala wrote:
> Ben Hutchings wrote:
> > The major input into the new seed file contents is the old seed file
> > contents. You are adding very little entropy on x86, and possibly
> > almost none on other architectures.
> >
> > Please reconsider this, as
On Mon, Feb 25, 2019 at 03:53:09PM +, Ben Hutchings wrote:
The major input into the new seed file contents is the old seed file
contents.
Yes, I'd just drop the seed file once used, then have a scheduled job
write a new one at some point in the future if the random quality is
high enough.
On Sun, 2019-02-24 at 19:52 +, Thorsten Glaser wrote:
[...]
> I’ve written something, a linux-any package, that…
>
> • during postinst, creates a 128-byte random seed file in /
> • updates that in a daily cronjob (using same tool as during
> boot except with more bits taken from the kernel)
On Sun, 2019-02-24 at 20:10 +, Thorsten Glaser wrote:
> Hi Philipp,
>
> >FTR this is supposedly fixed on the main architectures featuring an
> RNG
> >in the CPU by linux 4.19.20-1, which enabled RANDOM_TRUST_CPU. Which
> Ben
>
> that’s what I referred to by…
>
> >>• it does not use/add CPU
On 24/02/2019 20:00, Philipp Kern wrote:
On 2/24/2019 8:52 PM, Thorsten Glaser wrote:
In buster/sid, I noticed a massive delay booting up my laptop
and some virtual machines, which was reduced by hitting the
Shift and Ctrl keys multiple times randomly during boot; a
message “random: crng init
Uoti Urpala dixit:
>entropy to be secure. Consider the following scenario:
>
>Daemon
There are no daemons running at that time. This is run in
initramfs, just after the root filesystem has been mounted,
with no background tasks save udev running, and network has
not been set up (unless NFS or
Hi Philipp,
>FTR this is supposedly fixed on the main architectures featuring an RNG
>in the CPU by linux 4.19.20-1, which enabled RANDOM_TRUST_CPU. Which Ben
that’s what I referred to by…
>>• it does not use/add CPU RNG output where present
>> ‣ though Linux can now do that itself, some
On 2/24/2019 8:52 PM, Thorsten Glaser wrote:
> In buster/sid, I noticed a massive delay booting up my laptop
> and some virtual machines, which was reduced by hitting the
> Shift and Ctrl keys multiple times randomly during boot; a
> message “random: crng init done” would appear, and boot would
>
Hello fellow developers (and some users),
I would like to present a recent (this week) project of mine.
Background story:
In buster/sid, I noticed a massive delay booting up my laptop
and some virtual machines, which was reduced by hitting the
Shift and Ctrl keys multiple times randomly during
Hi,
Just FYI, as RHEL8beta release note says(*) "Python 2.7 is available in
the python2 package. However, Python 2 will have a shorter life cycle and
its aim is to facilitate smoother transition to Python 3 for customers".
I'm not sure but if we would ship python2.7 in bust
Hi,
One of my floss friend noticed to me that phoronix reports Atheros
Publishes Open-Source WiFi Firmware
http://www.phoronix.com/scan.php?page=news_itempx=MTMyNTY
Source is https://github.com/qca/open-ath9k-htc-firmware and its license
seems to be DFSG-free one.
Now Debian provides it
On Tue, Mar 12, 2013 at 11:48:44PM +0900, Hideki Yamane wrote:
Hi,
One of my floss friend noticed to me that phoronix reports Atheros
Publishes Open-Source WiFi Firmware
http://www.phoronix.com/scan.php?page=news_itempx=MTMyNTY
Source is https://github.com/qca/open-ath9k-htc-firmware
On Tue, 12 Mar 2013 19:15:20 +
Ben Hutchings b...@decadent.org.uk wrote:
This should be added to the linux-firmware.git repository and then to
our firmware-free source package. Perhaps you could talk to the
Atheros developers and you or they could prepare a patch for
linux-firmware.git?
On Wed, 2013-03-13 at 11:13 +0900, Hideki Yamane wrote:
On Tue, 12 Mar 2013 19:15:20 +
Ben Hutchings b...@decadent.org.uk wrote:
This should be added to the linux-firmware.git repository and then to
our firmware-free source package. Perhaps you could talk to the
Atheros developers and
On Wed, Mar 13, 2013 at 10:13 AM, Hideki Yamane wrote:
Okay, but they are using patched gcc and binutils for build it.
So I guess, first it should be merged to upstream gcc/binutils, then
be added to firmware git repo, right?
No, that is not how the firmware-free source package works. It
On Wed, 2013-03-13 at 10:27 +0800, Paul Wise wrote:
On Wed, Mar 13, 2013 at 10:13 AM, Hideki Yamane wrote:
Okay, but they are using patched gcc and binutils for build it.
So I guess, first it should be merged to upstream gcc/binutils, then
be added to firmware git repo, right?
No,
folgende aenderungen werden in kuerze deployed..
commit e8a6bbdf2efc0ed75058f53e72d8f202f3f0ac27
Author: Daniel Baumann d.baum...@netstyle.ch
Date: Wed Aug 29 14:00:38 2012 +0200
Removing hazardous alias of 'ls -la' on '.', this is dangerous,
don't do such things.
commit
sorry for the noise.. wrong list due to address auto-completion failure.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/503e2131.6020...@netstyle.ch
On Fri, 3 Sep 2010 20:12:28 +0200, Iustin Pop wrote:
After some discussion on how the actual links should be presented so
that uscan can find them while still keeping the desired UI
behaviour, the a href=… links are now back in and the DEHS data
for projects hosted on code.google.com should
Hi all,
[resend since my original mail from Aug 26th got lost]
As promised during Debconf, I went and talked with the code.google.com
people about the changes to the download list which broke uscan. For the
record, the rationale for the changes was (quoted with permission):
Background: We used
On Fri, Sep 03, 2010 at 08:12:28PM +0200, Iustin Pop wrote:
After some discussion on how the actual links should be presented so
that uscan can find them while still keeping the desired UI behaviour,
the a href=… links are now back in and the DEHS data for projects
hosted on code.google.com
On Fri, 3 Sep 2010 20:12:28 +0200, Iustin Pop wrote:
After some discussion on how the actual links should be presented so
that uscan can find them while still keeping the desired UI behaviour,
the a href=… links are now back in and the DEHS data for projects
hosted on code.google.com should
On Fri, Sep 03, 2010 at 09:10:02PM +0200, David Paleino wrote:
On Fri, 3 Sep 2010 20:12:28 +0200, Iustin Pop wrote:
After some discussion on how the actual links should be presented so
that uscan can find them while still keeping the desired UI behaviour,
the a href=… links are now back
On Fri, 3 Sep 2010 21:37:21 +0200, Iustin Pop wrote:
On Fri, Sep 03, 2010 at 09:10:02PM +0200, David Paleino wrote:
On Fri, 3 Sep 2010 20:12:28 +0200, Iustin Pop wrote:
After some discussion on how the actual links should be presented so
that uscan can find them while still keeping
On Fri, Sep 03, 2010 at 10:02:15PM +0200, David Paleino wrote:
On Fri, 3 Sep 2010 21:37:21 +0200, Iustin Pop wrote:
On Fri, Sep 03, 2010 at 09:10:02PM +0200, David Paleino wrote:
On Fri, 3 Sep 2010 20:12:28 +0200, Iustin Pop wrote:
After some discussion on how the actual links
On Wed, May 13, 2009 at 01:58:12AM +0200, Goswin von Brederlow wrote:
Osamu Aoki os...@debian.org writes:
Hi,
When my usual web page updates failed, I was checking my ethernet
connection ... I wondered why ... Here is the reason:
I might have missed some announcment, ... but it
Hi,
When my usual web page updates failed, I was checking my ethernet
connection ... I wondered why ... Here is the reason:
I might have missed some announcment, ... but it seems rsync on
people.debian.org creates directories and files with 700 permission.
This is new behavior. If you are
Osamu Aoki os...@debian.org writes:
Hi,
When my usual web page updates failed, I was checking my ethernet
connection ... I wondered why ... Here is the reason:
I might have missed some announcment, ... but it seems rsync on
people.debian.org creates directories and files with 700
Hi,
On Fri, May 23, 2008 at 02:05:14PM +1000, Brian May wrote:
Osamu Aoki wrote:
Shorter summary of vote data goes as:
cvs 5%
subversion9%
git-core 3%
mercurial 0.6%
darcs 0.3%
bzr 0.3%
Does monotone not get a mention? or was monotone missed?
On Thu, May 22, 2008 at 12:31:09PM -0400, Felipe Sateler wrote:
Osamu Aoki wrote:
Then you are voting for mercurial if you participated in popcon.
vote: number of people who use this package regularly;
Note that the vote is not that reliable either: it needs atime, which is
getting
Hi,
I did not mean to say that VCS in low numbers are unpopular. Instead, my
message should be understood as there are many popular VCSs and
popularity of use is moving.
On Wed, May 21, 2008 at 10:27:40PM +0200, Michal Čihař wrote:
Dne Wed, 21 May 2008 15:10:14 -0500
Steve Greenland [EMAIL
* Osamu Aoki [EMAIL PROTECTED] [080522 14:36]:
The large installed with low vote may be indication that people has
found some new good alternative for a popular tool of yesterday.
(RCS - DVCS such as git, mercurial, ...)
I think this is only a part of an explanation and more suiteable
for
On Thu, May 22, 2008 at 01:15:18AM +0900, Osamu Aoki wrote:
One of the most interesting thing I noticed by doing this was change in
popularity of VCS. (Just 1/2 year r so).
Readers of this thread might be interested in the popularity of VCS used
to _maintain_ Debian packages. Since a few days
Osamu Aoki wrote:
Then you are voting for mercurial if you participated in popcon.
vote: number of people who use this package regularly;
Note that the vote is not that reliable either: it needs atime, which is getting
less and less used.
--
Felipe Sateler
--
To UNSUBSCRIBE, email
Osamu Aoki wrote:
Shorter summary of vote data goes as:
cvs 5%
subversion9%
git-core 3%
mercurial 0.6%
darcs 0.3%
bzr 0.3%
Does monotone not get a mention? or was monotone missed?
Brian May
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a
Hi, (Composed as UTF-8 mail with graphic characters)
I have been trying to update debian reference. As a part of this
effort, I made snapshot of popularity of packages.
One of the most interesting thing I noticed by doing this was change in
popularity of VCS. (Just 1/2 year r so).
When I
On 21-May-08, 11:15 (CDT), Osamu Aoki [EMAIL PROTECTED] wrote:
Hi, (Composed as UTF-8 mail with graphic characters)
I have been trying to update debian reference. As a part of this
effort, I made snapshot of popularity of packages.
One of the most interesting thing I noticed by doing
On Wed, May 21, 2008 at 03:10:14PM -0500, Steve Greenland wrote:
On 21-May-08, 11:15 (CDT), Osamu Aoki [EMAIL PROTECTED] wrote:
Hi, (Composed as UTF-8 mail with graphic characters)
I have been trying to update debian reference. As a part of this
effort, I made snapshot of popularity of
Dne Wed, 21 May 2008 15:10:14 -0500
Steve Greenland [EMAIL PROTECTED] napsal(a):
FWIW, and I'm not sure it actually conflicts or invalidates or even
causes questions of the popcon data, but installs, at least, may not
mean that much. On my main home box, several years old now, I've got all
of
Steve Greenland [EMAIL PROTECTED] writes:
FWIW, and I'm not sure it actually conflicts or invalidates or even
causes questions of the popcon data, but installs, at least, may not
mean that much. On my main home box, several years old now, I've got
all of cvs, svn, rcs[1], mercurial, git, and
Hi fellow Debian people,
noticing all the recent discussions about sourcev2/v3, git.tar.gz,
and other VCS-related stuff, I thought I could get away with
dropping a quick pointer to http://vcs-pkg.org, which I hope can
become a central resource for the topics we're discussing.
Also, if you would
Hello All,
I went through the whole set of failing builds for mips, fixed some
bugs and had at least a cursory look at each package. The result is
the rather terse list I append here.
Thiemo
Debian mips port, buildability status 2007-11-03. See also:
Hi interested parties,
On 26-Apr-2007 15:24.21 (BST), Stephan Suerken wrote:
Generally speaking about packaging, my intend was to drop uae in
favour of e-uae in post-etch, and I would also like a practical
setup to allow group-maintaining (considering the time restrictions
I suffered
For the small handful of people use dxpc (differential X protocol
compressor, a useful tool for running X over slow network connections
even including dialup), you should be aware that I have just uploaded
3.9.0-1 to sid. Version 3.9.0 is not runtime compatible with older
versions of because of
* Jay Berkenbilt ([EMAIL PROTECTED]) wrote:
For the small handful of people use dxpc (differential X protocol
compressor, a useful tool for running X over slow network connections
even including dialup), you should be aware that I have just uploaded
3.9.0-1 to sid. Version 3.9.0 is not
Hi,
I got a bugreport requesting exected mirror sizes to be added to the
debmirror documentation and I thought some of you might be intrested
in them too. So heres the stats:
Mirror size for a singe arch and binary only (in MiB):
| sarge | etch | sid | all
* Goswin von Brederlow:
Mirror size per arch (in MiB):
| sarge | etch | sid | all
-+---+--+---+---
source | 9339 | 9419 | 11495 | 30252
This looks suspicious. I expected that the total number would be
significantly less than the sum of the suites
Florian Weimer [EMAIL PROTECTED] writes:
* Goswin von Brederlow:
Mirror size per arch (in MiB):
| sarge | etch | sid | all
-+---+--+---+---
source | 9339 | 9419 | 11495 | 30252
This looks suspicious. I expected that the total number would be
Would anybody at Debian be interested to discuss my lmbench results attached
below (comparing vanilla Linux 2.6..8-rc4 kernel with and without kernel
preemption option running on PQ2FADS-VR with MPC 8275) ?
Thanks
-Original Message-
From: Povolotsky, Alexander
Sent:
http://www.infrastructures.org/papers/bootstrap/bootstrap.html
--
Karl M. Hegbloom [EMAIL PROTECTED]
Karl M. Hegbloom said on Tue, Jul 22, 2003 at 02:01:19AM -0700:
http://www.infrastructures.org/papers/bootstrap/bootstrap.html
While this is a good paper, and there are lots of interesting ideas contained
within it that map well to Debian (I've got 50 or so Debian boxes in a
configuration
Hi,
SDL_ttf's current maintainer is no longer interested in it and
doesn't mind giving it away.
In addition, version 2 has been released for some time now.
Cheers,
--
Jérôme Marant
http://marant.org
Ethan Benson [EMAIL PROTECTED] wrote:
On Sun, Apr 22, 2001 at 09:00:13AM -0400, Itai Zukerman wrote:
you want. The postinst code would call the compression routines,
which might not do anything, depending on how the compressing package
was configured (i.e., it wouldn't call the compressing
On Tue, 24 Apr 2001 13:14:36 +0100, [EMAIL PROTECTED] (Colin Watson) wrote:
you want. The postinst code would call the compression routines,
which might not do anything, depending on how the compressing package
was configured (i.e., it wouldn't call the compressing code directly,
but
On Tue, Apr 24, 2001 at 01:14:36PM +0100, Colin Watson wrote:
Ethan Benson [EMAIL PROTECTED] wrote:
On Sun, Apr 22, 2001 at 09:00:13AM -0400, Itai Zukerman wrote:
you want. The postinst code would call the compression routines,
which might not do anything, depending on how the compressing
On Tue, Apr 24, 2001 at 09:14:41AM -0400, Itai Zukerman wrote:
It seems to me that each maintainer should make the decision of
whether she wants UPX to apply to any of her binaries. And the
easiest way to do that, IMO, is to have her add
[ -x install-upx ] install-upx /usr/bin/foo
On Tue, 24 Apr 2001 05:30:18 -0800, Ethan Benson [EMAIL PROTECTED] wrote:
[ -x install-upx ] install-upx /usr/bin/foo /usr/bin/bar
to her postinst or
fine
dh_upx
to her rules.
NO! this would absolutly suck. that leaves the admin in the position
to have to rebuild the
Recent versions of upx can compress a linux bzImage (I've seen 13% shaved off
a bzImage). debian-installer may use it to squeeze more onto the single
floppy (kernel + initrd with modules).
David
Sat, Apr 21, 2001 at 06:25:10PM -0700 wrote:
On Sat, 21 Apr 2001, John H. Robinson, IV wrote:
On Sun, Apr 22, 2001 at 11:39:07PM -0700, David Whedon wrote:
Recent versions of upx can compress a linux bzImage (I've seen 13% shaved off
a bzImage). debian-installer may use it to squeeze more onto the single
floppy (kernel + initrd with modules).
Isn't that slightly redundant? A bzImage
Alexander Hvostov [EMAIL PROTECTED] wrote:
Since UPX only runs when a program is loaded, and only takes a few seconds
to do its thing, I see no reason why weaker (eg, 486) machines couldn't
handle it. Even on old 386 machines, the slowdown shouldn't be much of a
headache, unless what's being
On Mon, Apr 23, 2001 at 11:35:12AM +0100, Colin Watson wrote:
Incidentally, I assume the temporarily decompressed executables created
by UPX are mode 700?
I would hope that they have the same permissions as the originals. And
I don't want to imagine what might happen with a suid excecutable...
Aaron == Aaron Lehmann [EMAIL PROTECTED] writes:
Aaron I would hope that they have the same permissions as the
Aaron originals. And I don't want to imagine what might happen with
Aaron a suid excecutable...
The unstable version of UPX (1.11) doesn't use the tempfile approach
anymore.
From
On Sat, Apr 21, 2001 at 07:42:00PM -0300, Carlos Laviola wrote:
There is: just upx -d it. (you can even run md5sum before and after
compression/decompression to find out for yourself that the decompressed file
is the same as before.)
Will upx -d work on a binary that was compressed with an
On Sun, 22 Apr 2001 00:57:54 +0200, [EMAIL PROTECTED] wrote:
On Sunday 22 April 2001 00:45, Itai Zukerman wrote:
Why not compress the binaries in the postinst, maybe after asking the
admin for permission?
Well, if I had to answer no to compression for binary in every new package
I
On Sun, Apr 22, 2001 at 09:00:13AM -0400, Itai Zukerman wrote:
If not, I suggest a debhelper command to add the necessary code to
the postinst. Packages that use this should, of course, depend on the
binary-compressing package, which would provide the one-time question
why should they
On Sun, 22 Apr 2001 06:02:30 -0800, Ethan Benson wrote:
On Sun, Apr 22, 2001 at 09:00:13AM -0400, Itai Zukerman wrote:
If not, I suggest a debhelper command to add the necessary code to
the postinst. Packages that use this should, of course, depend on the
binary-compressing package, which
On Sat, Apr 21, 2001 at 11:50:44AM -0700, John H. Robinson, IV wrote:
On Sat, Apr 21, 2001 at 11:41:56AM -0700, Alexander Hvostov wrote:
On Sat, 21 Apr 2001 11:40:15 -0700 John H. Robinson, IV wrote:
however, on something like boot-floppies, this might be a
goddess-send.
What
On Sat, Apr 21, 2001 at 12:20:21PM +0200, Eduard Bloch wrote:
What is upx good for?
For all applications that are not used in critical environment, i.e.
without enough free disc space, or when they are started to often, so
the decompression time may be too long.
For example, I will compress
On Mon, Sep 20, 1999 at 02:46:09PM -0700, Joey Hess wrote:
Raul Miller wrote:
Also, if you can anticipate any failure modes where sash would damage
the password file I'd appreciate hearing about them. It's already
the case that if sash has any problem writing out the new password
file
On Mon, Sep 20, 1999 at 06:02:47PM -0400, Greg Johnson wrote:
Here's one (happend to me). I have a '+' at the end of my /etc/passwd file
for nis. sash tried to add the new root acccount at teh end of /etc/passwd
AFTER the +. didn't work.
That was sash 3.3-5
Sash 3.3-6 already addresses
Raul Miller wrote:
They don't touch the root account. Instead, they clone
it as sashroot and set the shell on the cloned account.
This is mentioned in the package description.
On Sun, Sep 19, 1999 at 03:39:30PM -0700, Joey Hess wrote:
I suppose you have considered the security
On Sun, 19 Sep 1999, Raul Miller wrote:
There's not a lot I can do about this beyond advising the sysadmin that
it's a good idea.
what about asking it before doing the actual cloning ? (should be
defaulted to no, imho). as i see the postinst for 3.3-6,
it does not ask...
--
[-]
On Sun, Sep 19, 1999 at 10:53:01PM -0400, Raul Miller wrote:
Raul Miller wrote:
They don't touch the root account. Instead, they clone
it as sashroot and set the shell on the cloned account.
This is mentioned in the package description.
On Sun, Sep 19, 1999 at 03:39:30PM -0700,
On Mon, Sep 20, 1999 at 01:37:43PM -0400, Andrew Pimlott wrote:
Will this affect people who upgrade? It would be very unpleasant to upgrade
from slink and have a new root user.
Hmmm...
Even for new installs, I disagree with your decision. sash is useful
without another root account; however
Raul Miller wrote:
Also, if you can anticipate any failure modes where sash would damage
the password file I'd appreciate hearing about them. It's already
the case that if sash has any problem writing out the new password
file that it won't install it.
I think you should just use useradd to
On Mon, Sep 20, 1999 at 02:20:12PM -0400, Raul Miller wrote:
Also, if you can anticipate any failure modes where sash would damage
the password file I'd appreciate hearing about them. It's already
the case that if sash has any problem writing out the new password
file that it won't install
1 - 100 of 110 matches
Mail list logo
