Hi.
Some time ago, I've wrote several bug reports to packages, that download
files from some non-apt-secured sources of the web, and install them.
I got more or less positive feedback from maintainers that happily
accepted my suggestions, to those who thought they were crap and not
necessary ;)
On Thu, 2009-09-17 at 23:13 +0100, Steve Kemp wrote:
> 4) The package downloads insecure code and directly executes it.
I'd have counted these to (1),... because downloading and "just"
installing means automatically, that it's likely to be executed at some
point.
Of course it's even worse if thi
On Fri, 2009-09-18 at 12:37 +0100, Jon Dowland wrote:
> Personally I dislike this mode of operation. I don't like
> lots of code running in postinsts as root to perform e.g.
> downloads (examples: flashplugin-nonfree) and subsequent
> processing (unpacking, running shell scripts, etc.).
Of course,.
On Thu, 2009-09-17 at 23:02 -0400, Michael S Gilbert wrote:
> checksums are a good start, but if the data itself is non-free (or
> closed or obscured), then how can you be sure it is not malicious?
Of course not at all but we should try to secure as much as possible
and close as many holes as p
On Fri, 2009-09-18 at 18:19 +0300, Tom Feiner wrote:
> Geoip upstream provides the source of these binary databases, so all we need
> to do is find a consistent and reliable way to get new database updates, built
> from source by debian and propagated through the usual apt repositories. This
> look
On Fri, 2009-09-18 at 12:22 -0400, Michael Gilbert wrote:
> however, i think that since these packages are depending on information
> outside of the debian archive, most (if not all) should be hosted under
> the contrib section (since users without internet access will encounter
> reduced/limited f
By the way,.. a similar problem is also present in many other packages.
Let me just name a few concrete examples so that you get a feeling on
what I mean.
1) debootstrap/cdebootstrap
IIRC, only cdeboostrap requires a keyring per default (or did it always
use debian-archive-keyring?)
Anyway,... w
On Tue, 2009-09-22 at 21:23 +0200, Patrick Matthäi wrote:
> There are so many scenarios where we are not able to verify any
> signatures (upstream does not provide any kind of verification) or where
> it is non-sens.
>
> If we are so pedantic about this topic, we should also ask ourself, if
> pack
Hi.
Ever thought about integrating PaX [0] per default in Debian?
I'm however not sure how much this actually breaks ;)
Cheers,
Chris.
[0] http://pax.grsecurity.net/
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas..
On Tue, 2009-10-27 at 09:32 +0800, Paul Wise wrote:
> Any idea if these patches will be merged upstream?
It's probably quite unlikely,... although I never understood why,..
Even though it's available for some architectures,.. it would improve
security at least on them.
Cheers,
--
To UNSUBSCRIB
On Tue, 2009-10-27 at 15:48 +0800, Paul Wise wrote:
> http://wiki.debian.org/DebianKernelPatchAcceptanceGuidelines
> http://kernel-handbook.alioth.debian.org/ch-source.html#s-acceptance
The thing is,..
A patch like PaX would (IMHO) improve security a lot,... and it would be
worth thinking for a dis
On Tue, 2009-10-27 at 22:19 -0200, Henrique de Moraes Holschuh wrote:
> Well, the issue raised in LKML is that you absolutely should *not* enable
> -fstack-protector-all unless you _really_ know what you're doing, and most
> certainly not by default. It has nothing to do with -fstack-protector, ju
Hi.
Then simply change the user agent (either manually or via one of the
available plugins)... or even better:
Contact the authors of your listed applications, to fix theirs instead
of "fixing" Iceweasel, which is totally fine as it is.
Cheers,
Chris.
--
To UNSUBSCRIBE, email to debian-devel
Klaus Ethgen wrote:
> A black day in the security of Debian. Well.. One more.
Absolutely true,... :-(
Now that we have Ubuntu as competitor, which is nicely coloured and
where everything "just works", let's try to imitate (and integrate
Ubuntu stuff) as much as possible.
Or even better,... let's
On Fri, 2010-05-14 at 17:16 -0700, Russ Allbery wrote:
> Why do you have this strong of a reaction to this change?
Because it shows - what I consider to be a - trend in Debian recently
that security dying more and more (again, I do not mean the work of the
Security Team).
- Debian does not ship wi
On Sat, 2010-05-15 at 02:18 +0200, Stefano Zacchiroli wrote:
> Guys, IMHO you really need to stop ranting contentlessly. Either you
> reply to the technical arguments in favor of the change that have been
> made (e.g. by Russ Allbery in this thread, to which you carefully
> avoided to reply thus f
On Fri, 2010-05-14 at 21:07 -0400, Joey Hess wrote:
> Your typical program with a dotfile relies on the user
> choosing a safe combination of umask and directory permissions for its
> security.
As you say,... it "relies on the user"...
At least half (!) of the bill (the default umask) is now taken
On Sat, 2010-05-15 at 02:55 +0200, Christoph Anton Mitterer wrote:
> - Many packages ship with configuration that is either really insecure
> or that could be at least hardened a lot.
Another nice (IMHO) example are the X.509 that are shipped per default
in several places (Mozilla N
On Sat, 2010-05-15 at 03:32 +0200, Andreas Marschke wrote:
> In that case why dont we as security aware people and people that think that
> more hardened defaults should be applied,
I think we (Debian as a collective) does apparently not think so, which
is probably _not_ specifically proven by tha
On Fri, 2010-05-14 at 22:22 -0700, Russ Allbery wrote:
> These are really odd complaints to bring against Debian given that these
> are not Debian issues. Firefox, for example, works exactly the same way
> everywhere. What do you want Debian to do, write our own web browser?
> There are limits to
On Sat, 2010-05-15 at 09:04 +0200, Tollef Fog Heen wrote:
> You can make that argument for just about all the daemons that are
> shipped in the distro.
Yes :)
> Should ssh not start by default or just listen
> to localhost for instance?
Personally,... I'd prefer the listen to localhost only (per
On Sat, 2010-05-15 at 10:04 +0200, Andreas Metzler wrote:
> #2 UPG with umask 022 is useless.
Why is it?
It makes that every user has its own group, and that other users can be
added to it.
This alone doesn't have any effect of course, as such added users have
read rights anyway.
But now it's easy
On Sat, 2010-05-15 at 14:16 +0300, Andrei Popescu wrote:
> for regular users
Would have to double check it,... but doesn't the current change also
affect root?
Cheers,
Chris.
smime.p7s
Description: S/MIME cryptographic signature
On Sat, 2010-05-15 at 13:22 +0200, Bernhard R. Link wrote:
> Sorry, adding one user to the group of another is almost as stupid as
> adding a script in /etc/cron.daily writeable by some user.
If the user who owns the group allows it? What else should I do in your
opinion?
Cheers,
Chris.
smime.p
On Sat, 2010-05-15 at 14:23 +0300, Andrei Popescu wrote:
> Why is an own group needed for this? Can't the admin just create groups
> as needed where both users shall belong?
Well but that's always possible isn't it? So one could drop the concept
of UPGs completely...
Cheers,
Chris.
smime.p7s
D
On Sat, 2010-05-15 at 13:22 +0200, Michael Biebl wrote:
> And why do you think this is a Debian specific problem is completely beyond
> me.
>
> This was an upstream bug, found by a fellow DD, and the quickly communicated
> to
> upstream and fixed there.
> I honestly don't see how you can blame D
On Sat, 2010-05-15 at 13:45 +0200, Holger Levsen wrote:
> This paragraph should be accompanied by something like:
>
> Instead of adding users to other users private groups (which has issues as
> explained above) it is recommend to create dedicated groups for these users
> for collaboration.
Per
On Sat, 2010-05-15 at 15:59 +0300, Andrei Popescu wrote:
> By default:
>
> # grep umask .bashrc
> umask 022
> #
Not in the most recent version of base-files, which does not update most
of it files.
Cheers,
Chris.
smime.p7s
Description: S/MIME cryptographic signature
On Sat, 2010-05-15 at 21:01 +0800, Paul Wise wrote:
> You might be interested in monkeysphere
...and in RFC 5081
I haven't had a detailed look on monkeyspehre so far, but it seemed at a
first glance, that it does not use standardised technology, does it?
Cheers,
Chris.
smime.p7s
Description: S/
On Sun, 16 May 2010 18:18:14 -0400, Felipe Sateler
wrote:
> Is there a reason to support non-UPG systems?
Not to force users to use anything that they don't want?
btw: While I stopped at some point commenting that issue, when I realised
that general security concerns were simply ignored,... I've
On Mon, 17 May 2010 00:12:56 -0400, Micah Anderson
wrote:
> Can you clarify what you mean by "standardised technology"? I work on
> the monkeysphere project, and from my point of view, I'd have to
> disagree with you, but I may not understand what you mean.
What I mean was simply something that is
On Mon, 17 May 2010 10:31:44 +0200, Holger Levsen
wrote:
> how about you file bugs _with patches_? Talk is cheap.
Well the only patches I could write with pure conscience would be:
- change umask from 022 or 002 to either 027 (or 077).
- disable UPGs altogether, as I feel that they contradict the
On Mon, 2010-05-17 at 09:40 -0400, micah anderson wrote:
> RFC 5081 is still quite a while off from widespread adoption. When it is
> more widely adopted, we will be in a much better situation, until then
> the monkeysphere is operating as an interim translation step (keeping
> the on-the-wire prot
As far as I understood,... you guys are already starting to patch
unrelated software just to make UPG work (see
#581919).
Even the title of that "bug", "bad ownership or modes..." is
ridiculous... and proves what I've predicted before, namely that these
changes will compromise security (such a pa
On Mon, 2010-05-17 at 11:23 -0600, Aaron Toponce wrote:
> You haven't shown any implementation that security will be compromised
> in any way. You just keep throwing it around, which isn't doing anything
> for the discussion.
Uhm, no!
If you need to change for example ssh, to allow an authorized_k
On Mon, 2010-05-17 at 11:50 -0600, Aaron Toponce wrote:
> How does this compromise security when you're the only member of your
> private group?
And if you are not?
Why should you? Well someone simply might not want to use UPG? Or might
use the users or staff group?
Or do "we" now basically force
Hi Peter.
On Tue, 18 May 2010 09:48:15 +0200, Peter Palfrader
wrote:
> Anyway, my point remains: Procedures that were perfectly fine and
> secure up until now would suddenly be broken and dangerous.
I guess you're wasting your time... the many arguments which either showed
concrete technical (se
On Tue, 18 May 2010 10:08:17 + (UTC), Philipp Kern
wrote:
> So you present that as universal facts as if you've booked the truth
> (possibly a bad translation of a German saying).
No,.. and normally I would simply shut up, as I'm not even DD... but this
here breaks simply so much which I belie
On Tue, 18 May 2010 12:32:56 +0200, Christian PERRIER
wrote:
> evolutions that are apparently an evidence for all
> other distros.
Apart from whether everything what other do or do not is automatically an
evolutions (e.g. dotnet/mono)...
is there a list of distros that have UPGs fully deployed?
On Tue, 2010-05-18 at 17:38 +0200, Hendrik Sattler wrote:
> Do e.g. backup system deal well with ACLs?
Definitely not all,... but I guess those should be fixed anyway (totally
regardless of UPGs/umask issues)...
> The standard tar doesn't, except
> when you script around it... or if you use sta
Hi.
AFAIK, even Chrome has disabled most tracking stuff per default (except
those things which FF/etc. do too).
With chromium, it was regarded to be a (reportable) bug if anything that
is privacy sensitive could not be disabled, IIRC.
And regarding Iron,... the following might be interesting:
ht
On Wed, 19 May 2010 22:51:25 +0200, Willi Mann wrote:
> The gain would be a guard against accidental 002 umasks in non-UPG
> environments, which I'm quite sure will happen. Either because admins do
> not
> read the release notes or because they forget to do the change on one of
> their newly-in
btw: What happened to the idea of movin umask completely away from
/etc/profile?
I mean regardless of the discussion about UPGs and which value is the
"best" default for umask, I found it to be a good idea to drop it there.
Can someone please explain me the reason why login.defs isn't used for
tha
On Wed, 19 May 2010 15:22:04 -0600, Aaron Toponce
wrote:
> You've only mentioned that SSH won't operate if the write bit is set on
> the keys or anything under the ~/.ssh/ directory. Can you explain how an
> ssh client failing to connect to an external ssh server because of the
> umask is compromi
On Thu, 20 May 2010 00:22:02 +0200 (CEST), Santiago Vila
wrote:
> If an admin which runs out of UIDs in his system modifies
> /etc/adduser.conf, will he remember to modify the upper bound in
> /etc/profile as well?
If these changes are going to be permanent and the discussion about them
has been a
Hi.
I guess it will take some time until Debian has switched to some
event-driven init-system, right? Especially as there seem to be multiple
systems for this ;)
On Fri, 2010-06-04 at 02:49 +0200, Petter Reinholdtsen wrote:
> Those wanting another ordering can edit the init.d scripts directly t
Hi folks.
I recently got my first SSD payed by my university and, even though
modern SSDs seem to have smart wear leveling algorithms and more and
more parts of kernel/userspace support TRIM, I was thinking about what
one can do to improve its lifetime.
The most obvious things I found were:
- /tm
On Sun, 2010-06-06 at 10:28 +0400, Michael Tokarev wrote:
> > - optionally /var/tmp as tmpfs
> Not an answer to your original question, just a not-so-random observation.
> /var/tmp is declared by LFS as "temporary storage that persists across
> reboots". It wont be this way if it's on tmpfs obviou
Hi folks.
IIRC, Jonas already put some of these issues up here some time ago.
I was recently investigating, and thanks to the help of many people
found out how deep the problems actually are.
Following a discussion at lkml
(http://thread.gmane.org/gmane.linux.kernel/1003210), I've decided that
it
Hi.
WTF?!
I really wonder how this (#579796), especially with such a license can
even be considered for going into Debian (especially seeing it in the
NEW queue yes I know, that this doesn't mean it has already been
acceptet).
1) I'm generally quite sceptical about putting religious stuff into
Hi.
I do not see how a event based initsystem would us actually help (but
perhaps I just don't understand it well enough).
I mean an event would be something like "mount root-fs" but then it
would be still completely open, on what to actually do for that.
I'm also do some thinking/planning on
On Fri, 2010-07-02 at 00:34 +0200, Patrick Matthäi wrote:
> There are also groups of people, which see porn as quite problematic at
> all, but we have got pornviewer e.g.. The software does not discrimate
> anyone, so why should we care about it?
Good argument...
The question however is,... who dec
On Fri, 2010-07-02 at 00:39 +0200, Mehdi Dogguy wrote:
> The software is meant for non-free. Why it should be rejected? Even
> non-free stuff has to pass NEW for the first upload…
See points (1-4) from my original post, which are not change at all by
using non-free.
I mean even something like:
"Th
On Thu, 2010-07-01 at 22:45 +, brian m. carlson wrote:
> I believe there is precedent for this. I remember seeing a program
> under a license written entirely in Japanese. When translated by a DD
> fluent in Japanese, it was found to be a simple 3-clause BSD-style
> license which is entirely
On Fri, 2010-07-02 at 01:24 +0200, Adam Borowski wrote:
> You're looking for tmpfs and pivot_root. The latter is a hack that's needed
> only because of kernel threads, if you're the only process chroot() and
> chdir() should be enough.
Of course,.. I rather meant,.. whether there are chances that
On Fri, 2010-07-02 at 09:48 +0200, Mehdi Dogguy wrote:
> You seem to have missed some funny licenses already used in the non-free
> area.
> As an example, did you read
> http://lists.debian.org/debian-legal/2010/03/msg00064.html ?
It's funny... yes... but there is no discriminatory or similar cont
On Fri, 2010-07-02 at 09:05 +0200, Joerg Jaspert wrote:
> Check again, this is meant for non-free, not main.
Still do not see how this would change anything... well of course rules
may say that we may put anything into non-free if it's distributable,...
but then we need some better rules.
> Oh su
On Fri, 2010-07-02 at 16:12 +0430, Mohammad Ebrahim Mohammadi Panah
wrote:
> > I guess it's quite easy for to judge things like this using common
> > sense...
> I don't think my common sense is anything near yours. Isn't Debian
> supposed to be for all of us?
Well... then apparently at least not fo
Hey
Well I guess that it's much easier to judge what's evil and what's not.
Typically all peoples that took part in the Enlightenment a scientific
development came to similar rules, which you can find things like:
- Universal Declaration of Human Rights
- European Convention on Human Rights
-
Hi.
I wonder why this never came up before,.. or did it an I'm just blind?
I've just read parts of POSIX, where echo is more or less deprecated in
favour of printf
(http://www.opengroup.org/onlinepubs/9699919799/utilities/echo.html#tag_20_37_16).
Whether users will do this or not is a different q
On Wed, 2010-07-14 at 19:22 +0200, Petter Reinholdtsen wrote:
> I believe this is a misunderstanding. The quoted section do not mean
> that all files in a essential package need to be on the root
> partition, but that the package should always be installed.
Well but what's the benefit then at all?
On Thu, 2010-07-15 at 12:09 +0200, Giacomo A. Catenazzi wrote:
> System initialisation and in general system script are outside POSIX
> scope, as well many common command executed by such scripts
> (administration tools are also outside POSIX).
Well yes,... nevertheless I guess that it's always a
On Wed, 2010-07-14 at 19:26 +0200, Sven Joachim wrote:
> It's been reported as bug #428189 already, but without any followup.
> See also #532324.
Well while 532324 is a perfect example how some developers obviously
think they can ignore the policy just as they like (this issue is really
unbelievabl
On Thu, 2010-07-15 at 14:59 +0200, Giacomo A. Catenazzi wrote:
> Yes, and usually it is so. In a short period the maintainer will
> receive bug report about non working init.d script with some
> configuration, which force people to minimize the init scripts.
Agreed.
> Early init script doesn't ne
On Thu, 2010-07-15 at 10:26 -0700, Russ Allbery wrote:
> Right, the point is that other packages can assume those binaries are
> available during any normal package operations and during package
> installation and removal.
Ok... than perhaps one can add a note to the policy, that this means
"after
On Thu, 2010-07-15 at 20:15 +0100, Julien Cristau wrote:
> No, and there doesn't need to be. Now can you stop beating this dead
> horse? It would like to rot in hell unharmed.
Wow,... supposing that you speak for Debian,... this reaction is
really ... "interesting"...
Always thought that Debian
On Fri, 2010-07-16 at 11:18 +0200, Mike Hommey wrote:
> So until the program actually does what it is intended to, I'm not
> exactly sure it is safe to put it in /sbin. OTOH, I could rename it, but
> except for nitpicking, what exactly would be the point?
So then let's downgrade the severity and le
On Fri, 2010-07-16 at 12:11 +0200, Giacomo A. Catenazzi wrote:
> Also the booting system is a changing area
> We moved from sysv style to inserv,
Isn't that still sysv + just some auto-"ordering" and so?
> IMHO requiring that at call of /bin/init (the first program
> called in the new root filesy
On Thu, 2010-07-15 at 13:08 -0700, Russ Allbery wrote:
> It's after $remote_fs. Please don't assume that all non-local file
> systems are NFS.
Yeah sorry ;)
Having $remote_fs is a really nice way to secure that /usr/-stuff is
there (and also other stuff like /var...)
As far as I understand - ple
On Thu, 2010-07-15 at 16:31 -0500, Peter Samuelson wrote:
> What problem are you trying to solve? Did you actually try to use an
> init script that use printf and doesn't depend on $remote_fs, on a
> system where /bin/sh is neither bash nor dash?
>
> Or is this just a big gedanken-experiment?
Adm
On Fri, 2010-07-16 at 20:02 +0200, Julien Valroff wrote:
> As long as init scripts are stored in /etc/init.d [0], I guess /etc is
> considered as being always available (even as read-only), am I right?
Sir! I take a bow :)
*bompf* That was too obvious for me to see it *G*
Cheers,
Chris.
sm
On Fri, 2010-07-16 at 19:23 +0100, Ben Hutchings wrote:
> I would think almost all init scripts depend on /dev and /proc! Certainly
> start-stop-daemon uses them.
I guess Russ meant,... whether I have any examples for
services/daemons,.. that need _just_ /proc or /dev,... but do not
already depend
On Fri, 2010-07-16 at 20:11 +0200, Petter Reinholdtsen wrote:
> /var/ is not required to be on the root file system, but
> must be available after the $local_fs point during boot.
Ah.. good to know,.. thought that could perhaps also be on
remote-filesystems...
> > Also, right after the init system
On Fri, 2010-07-16 at 18:13 -0400, Will wrote:
> > Ah.. good to know,.. thought that could perhaps also be on
> > remote-filesystems...
> What about services that start before $remote_fs is provided that
> place pidfiles in /var? Portmapper is an example of this.
Ok... I should have said "parts of
Hey
Should we then perhaps do the same with nfs4-acl-tools?
Cheers,
Chris.
smime.p7s
Description: S/MIME cryptographic signature
On Fri, 2010-07-23 at 12:26 +0200, Julien BLACHE wrote:
> Moreover, it'd be consistent with having chmod and chown in /bin.
btw: Consistency was the main reason for me to raise the question
whether other acl tools (nfs4) should be moved, too then.
But Maximiliano is right,... I also do not see any
On Sun, 2010-07-25 at 22:16 +0100, Roger Leigh wrote:
> Ideally POSIX ACLs should be binned and replaced wholesale with
> NFS4 ACLs.
You have my vote... but I guess that's rather difficult to get in all
current filesystems and even for current developments (btrfs) only
POSIX 1e ACLs are conside
On Tue, 2010-08-10 at 22:29 +0200, Andreas Tille wrote:
> I just tried to give some advise about proper placement of database
> files in a Debian package and I was sure I could simply link to the
> relevant paragraph in policy but there is none. Is the usage of
> /var/lib/ just a reasonable habit
On Tue, 2010-08-10 at 03:15 -0600, Bruce Sass wrote:
> I was curious so...
> $ for f in /bin/* /sbin/*; do if [ "`file $f | grep ELF`" != "" ] ; then
> /lib/ld-linux.so.2 (0x46bad000)
> libpcre.so.3 => /lib/libpcre.so.3 (0xb7856000)
>
> Are these bugs just waiting to bite, or
Hi.
Just wondered about the status of /etc/environment...
It seems that this belongs to libpam... but is no longer created an
deprecated or at least for providing local information, right?
However,... some packages seem to still have a look at it, e.g. openssh
(greped through my /var/lib/dpkg/in
On Sat, 2010-08-14 at 16:18 -0700, Steve Langasek wrote:
> It's actually a bug that /etc/environment is no longer created by default;
Tested a bit more and it seems to be created,... but only when
installing the first time (i.e. when package was not installed before).
Reinstalling doesn't create it
Hi.
I'd like the idea... it would make home-dir creation here at the faculty
a lot more easier.
On Tue, 2010-08-03 at 11:08 +0200, Petter Reinholdtsen wrote:
> The location could for example be /etc/skel.d/
I'd however suggest e.g. /etc/adduser.d or so... or at least not skel.d
Conceptually the s
Well does this perhaps deserve it's own manpage? At least if it's
not deprecated?
I barely found any real documentation about it (how it's intended to be
used and so).
It seems to be
Some init-scripts on my system merely use it as a location for the local
settings, e.g. console-screen.sh, k
On Thu, 2010-08-19 at 18:48 +0200, Stéphane Glondu wrote:
> Is this still relevant, now that we have initrd?
Yes, because the initr makes only the root-fs available,... and perhaps resume
devices.
But not things like encrpyted /usr, etc. pp.
Cheers,
Chris.
--
To UNSUBSCRIBE, email to debian-d
On Fri, 2010-08-20 at 15:10 +, The Fungi wrote:
> This argument is somewhat circular, in that the machine from which
> I'm typing this message has /usr as part of the / filesystem, all of
> which is LUKS encrypted, and the generic Debian initrd is handling
> it just fine. Some built-in logic to
On Mon, 2010-08-23 at 06:29 +1200, Lars Wirzenius wrote:
> Out of curiosity, since this does not affect me directly: is there a
> need to update existing home directories? For example, if one adds new
> files to /etc/skel, those only affect new home directories created after
> the fact, the existin
You're aware that not only .bash_* and .profile can be distributed
by /etc/skel,... but any other config file (e.g. .vimrc) a specific site
or organisation may found useful for their users?
Or a predefined directory structure,... ssh config perhaps specific for
each user?
Cheers,
Chris.
--
To
On Wed, 2010-08-25 at 11:05 +0200, Goswin von Brederlow wrote:
> We already have the logic in there to mount anything as /.
Well. at least if it's a very plain setup... (see
http://wiki.debian.org/AdvancedStartupShutdownWithMultilayeredBlockDevices)
> /usr can't be
> any harder so that isn't
On Tue, 2010-09-14 at 16:56 +, brian m. carlson wrote:
> I suspect that those figures are because 2048 bits is the default size
> for RSA keys and 4096 bits is the largest size that GnuPG supports.
> Some specially patched versions of PGP can support keys of up to 16384
> bits, but IIRC those a
On Wed, 2010-09-15 at 15:14 +0200, Marco d'Itri wrote:
> I suppose that this was not the result of cargo cult engineering, so if
> these new recommended key values have been selected as the result of a
> process I am curious to know the rationale which lead to the choice.
> It really looks like a s
On Fri, 2011-01-14 at 07:58 +0900, Charles Plessy wrote:
> In the candidate version of the DEP, it is not recommended anymore to add an
> X-
> prefix to extra fields.
btw: Why was this removed? Adding the X- is not only conventional style
in email headers and many other RFCs but also (in a similar
On Fri, 2011-01-14 at 12:09 -0400, Joey Hess wrote:
> I probably misread DEP5 -- when it says "formatted text, no synopsis",
> it probably means that the entire field including the first line
> is treated as one thing. So both "Comment: foo\n" and "Comment:\n foo\n" are
> the same value.
I've also
Oh, and I've also would like to see the "X-" on personal license short
names.
Perhaps one could also add a namespace that is "privately" managed, but
still global, e.g. in the style of:
"org.example.license.foobar"
Specifying globally unique a license "foobar" from Example Org.
But not sure whet
On Sun, 2011-02-13 at 23:21 +0100, Patrick Matthäi wrote:
> since we have got a stable release with dkms now, I am asking myself, if
> it is still necessary to support module-assistant.
> dkms is IMHO the better system and maintaining two different systems for
> kernel modules is a bit bloated.
Wit
Hi.
IIRC, I've already posted this here some time ago...
A few days ago now, I've submitted #616729, suggesting Martin, that one
could possible improve mdadm's initramfs-hooks to only include something
in the initramfs, if really needed.
That turned out to become a more general discussion between
On Tue, 2011-03-08 at 11:47 +0800, Paul Wise wrote:
> I always wondered why my ext3/ext4 over LVM over LUKS rootfs (default
> d-i encrypted system) gets complained about just before shutdown (by
> both systemd and sysvinit)
This is because the "devices" cannot be stopped, as the root-fs is still
m
Hey Thijs.
On Thu, 2014-06-12 at 19:31 +0200, Thijs Kinkhorst wrote:
> You raise a lot of broad concerns under the header "holes in secure apt"
> which
> I'm afraid does not much to get us closer to a more secure Debian.
Well I admit, that first this is just a lot of words... but I think
that's
On Thu, 2014-06-12 at 20:16 +0200, Tollef Fog Heen wrote:
> > Supplying the Debian Root CA to people not using Debian could have been
> > easily done by a *single* site that uses a cert available in all
> > browsers... which offers the Debian Root CA for secure and "trusted"
> > download.
>
> Tha
On Thu, 2014-06-12 at 19:43 +0100, Wookey wrote:
> So it does default to signed downloads and SFAIK will always do this
> wether or not any keys are installed/available, unless explicitly disabled.
What I meant was the discussion here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=432309
i.e.
On Thu, 2014-06-12 at 23:06 +0200, Holger Levsen wrote:
> both flashplugin-nonfree and torbrowser-launcher are (or will be) in contrib
> (and thus not be part of Debian) for exactly those reasons you described.
Well I guess the reason for flash is rather the license, isn't it?
Anyway... just bec
1 - 100 of 351 matches
Mail list logo
