Re: bash exorcism experiment ('bug' 762923 & 763012)

[Wouter Verhelst]

On Sun, Oct 12, 2014 at 10:05:20PM +0200, Florian Weimer wrote:
> If you need array variables, it's likely that the script has grown so
> complex that switching to another language is a good idea.

/etc/init.d/nbd-client

It's not exactly *needed*; I could replace it with a set of eval
instructions. But that would make the code much less readable, IMO.

Shell array variables are not a misfeature, they have their uses.

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141015070017.gb8...@grep.be

Re: Any news about Blends in tasks selection (Was: Debian Installer Jessie Beta 2 release)

[Andreas Tille]

Hi Bas,

On Tue, Oct 14, 2014 at 07:19:36PM +0200, Bas Wijnen wrote:
> On Tue, Oct 14, 2014 at 11:20:02AM +0200, Andreas Tille wrote:
> > I admit I expected *you* to know about Blends for a while - but
> > considering the video recorded quote I think I was not wrong using this
> > chance to point this out for other readers of this mail as it is really
> > a fact that I always meet DDs who mix up this concept with derivatives.
> 
> I have heard about them for quite a while, indeed, but I must say that I
> never entirely understood what they are. I'm guessing I'm not alone in
> this.

You belong to a majority if I might conclude from my experience.  I have
no idea whether I should feel responsible for this but I'm fighting on
several fronts like the extensive documentation[1] and countless
talks[2] as well as trying to push newcomers into the topic by
sponsering their packages[3].

> So let me write what I think they are, and then you can correct
> me.  I've read the explanation on the wiki, but I'm still not sure if I
> understand it right.
> 
> I think a blend is a system you can install, which after installing is a
> regular Debian system, set up for a particular task.  Because it's a
> regualr Debian system, after installation packages can be installed and
> removed just like on any other Debian system, and any other system can
> be turned into a blend by installing the right packages.

For the moment the way to install Blends is to use the plain Debian
installer and afterwards install a bunch of metapackages.  There is one
exception Debian Edu / Skolelinux which uses dedicated installation
medias with pre-feeded debconf data.  There is a long standing
discussion whether Debian Edu deserves the term "pure" but I will not
dive into this can of worms since I do not want to spoil the general
picture here with details caused by a single bug (Debian Edu people will
know it by heart).  The lack of a missing installer for all other Blends
is a frequently criticised problem and I personally think this should be
fixed by the integration into the official boot cds since this fits to
the nature of Blends which are a subset of Debian.

I'd like to add some informal ideas about Blends to perhaps give a
better picture of the idea:

  - Several people entertain deriving from Debian and actually the never
ending misconception about Blends is that they are derivatives.  But
Blends are derivatives "done the right way" - by not deriving Debian
and rather do the adaptations inside Debian.  The goal is to save
time and prevent reinventing the wheel on the (non)derivers side and
to bundle forces right into Debian.
  - Blends are a way to advertise Debian in specific fields of interest
I personally started from a point where I wanted to reach a status,
that if somebody wonders what distribution to use for biology and
medical care the natural answer should be "Use Debian"  We could
easily reach this goal for other fields of interest if all our
dedicated experts we had in Debian would work on this direction in
their own field.
  - Blends is also about forming teams inside Debian to care for a
certain topic to serve as glue between upstream and the end user and
if you have watched[4] (as advised in my last mail) you not only get
an idea about how we form teams but about the Blends concept in
general.
 
> From the wiki, it seems that is just the "Pure Blend", because other
> Blends may have extra apt sources.

There might be additional apt sources but it is not only about apt
sources.  For instance (as far as I'm informed) all packages in Debian
Edu are inside Debian and there was just a need to change some
configuration change of some *other* packages which conflicts with
Debian policy (I'm pretty sure Jonas will respond in detail to this mail
- so I save my time here B-)).  The whole pure / non-pure discussion is
from my personal point of view a consequence of nitpicking about policy
compliance which was born out of the problem that some package
maintainers are not willing to accept some more flexible debconf
configuration options.  I agree that policy is something to be really
picky about and will not argue against this but on the other hand it
spoils a bit the simplicy to understand the whole concept.  So a "Debian
Pure Blend" (I use the shortcut "Blend" as a synonym) is fully
integrated into Debian while "non-pure" Blends are trying to approach
the full Debian integration but some minor pieces like a hand full of
packages or some policy conflicting stuff remain on their todo list.
 
> Is this a good summary?

I hope I added some more points to this summary.
 
> If so, I think it would be a very good idea to make this part of the
> installer.  And turn the default system into "just another blend".

Sounds like a nice view on the Blends concept. :-)
 
> Regardless of whether my summary is good, I think the documentation can
> use some improvement.

+1
That's always nee

Re: Any news about Blends in tasks selection (Was: Debian Installer Jessie Beta 2 release)

[Andreas Tille]

Hi,

On Tue, Oct 14, 2014 at 08:29:47PM +0200, Jonas Smedegaard wrote:
> 
>  Well, Blends and "the desktop situation" could be considered 
>  orthogonal.
> > 
> > Do all blends work well with all desktop environments?
> 
> No.

While this "no" means:  There exist 1 or 2 Blends focussing on a
specific desktop environment (as far as I know Debian Edu and Ezgo) but
others work perfectly well under all desktop environments.  So the
answer is mathematical correct but a bit short to understand the full
picture.
 
Kind regards

 Andreas.

PS: I'll answer Bas' question tomorrow in more detail but I'm to
tired today.

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-blends-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141014215750.ga4...@an3as.eu



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141014215750.ga4...@an3as.eu

Bug#765444: RFP: mustache-java -- Mustache (templating language) implementation in Java

[Hilko Bengen]

Package: wnpp
Severity: wishlist

* Package name: mustache-java
  Version : 0.8.17
  Upstream Author : Sam Pullara 
* URL or Web page : http://github.com/spullara/mustache.java
* License : Apache-2.0
  Description : Mustache (templating language) implementation in Java


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87tx35himq@msgid.hilluzination.de

Re: bash exorcism experiment ('bug' 762923 & 763012)

[Marco d'Itri]

On Oct 15, Wouter Verhelst  wrote:

> If you target posh, you target all shells that policy allows for --
> including those that are smaller and/or faster than dash.
Can you list some, and what benefits they would bring over dash?

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Any news about Blends in tasks selection (Was: Debian Installer Jessie Beta 2 release)

[Andreas Tille]

Hi Holger,

On Wed, Oct 15, 2014 at 10:25:20AM +0200, Holger Levsen wrote:
> Hi,
> 
> On Dienstag, 14. Oktober 2014, Andreas Tille wrote:
> > While this "no" means:  There exist 1 or 2 Blends focussing on a
> > specific desktop environment (as far as I know Debian Edu and Ezgo) but
> 
> Debian Edu offers you the documented choices between KDE Plasma (default), 
> Gnome, Mate, Xfce4, LXDE and Sugar. (And for jessie+1 hopefully Cinnamon 
> too.) 
> And as the documentation also says you can apt-get install anything else you 
> wish from Debian too.
> 
> So no, Debian Edu doesnt focus on a specific desktop anymore. A few years ago 
> KDE was *the* choice, but iirc that was until ~2009 or 10.

Thanks for the clarification.  In this case I'd answer the question from
Bas 

  > Do all blends work well with all desktop environments?

rather with "yes".

I'll send this to the other lists where the question came up to.  At
some point we should stop cross-posting to several lists, but since the
topic about the installer is relevant for debian-boot as well I'm not
sure whether it is good to leave this out.

Kind regards

  Andreas.

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141015091629.gk16...@an3as.eu

Re: bash exorcism experiment ('bug' 762923 & 763012)

[Thorsten Glaser]

On Mon, 13 Oct 2014, Stephane Chazelas wrote:

> $*, $@, "$*" were not special in any way. They just underwent
> the same rules as other variables. Only "$@" was.

This changed in POSIX sh though. I remember having
to change some things in mksh to adhere to 2008 and
post-2008.

bye,
//mirabilos
-- 
[16:04:33] bkix: "veni vidi violini"
[16:04:45] bkix: "ich kam, sah und vergeigte"...


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.11.1410151212100.30...@tglase.lan.tarent.de

Re: Built-Using, again…

[Thorsten Glaser]

On Mon, 13 Oct 2014, Wookey wrote:

> I _think_ we don't do this because the upgrading uses a lot of time on
> buildds, especially slow ones. I did do this (build in snapshot,

Right.

> the same packages over and over until the snapshot was updated (which
> was manual and done approx weekly). This particularly adds overhead to

I think we don’t do it weekly:

https://buildd.debian.org/status/fetch.php?pkg=mksh&arch=powerpc&ver=50d-1&stamp=1412710471

 Built-Using: gcc-4.9 (= 4.9.1-5), klibc (= 2.0.4-2), linux (= 3.14.15-2)

And it had libc6_2.19-9 installed.

For what it’s worth, the problem is still not solved.
Who are powerpc buildd admins, again?

Thanks,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.11.1410151257390.30...@tglase.lan.tarent.de

Re: Built-Using, again…

[Cyril Brulebois]

Thorsten Glaser  (2014-10-15):
> Who are powerpc buildd admins, again?

Still listed at the same location since last time you asked:
  https://www.debian.org/intro/organization
  https://lists.debian.org/debian-devel/2014/07/msg00446.html

KiBi.


signature.asc
Description: Digital signature

$*/$@/$IFS and Bourne vs Almquist vs Korn vs mksh (Was: bash exorcism experiment ('bug' 762923 & 763012))

[Stephane Chazelas]

2014-10-15 12:13:06 +0200, Thorsten Glaser:
> On Mon, 13 Oct 2014, Stephane Chazelas wrote:
>
> > $*, $@, "$*" were not special in any way. They just underwent
> > the same rules as other variables. Only "$@" was.
>
> This changed in POSIX sh though. I remember having
> to change some things in mksh to adhere to 2008 and
> post-2008.
[...]

The POSIX spec is very unclear if not misleading.

"Expands to the positional parameters, starting from one"
doesn't make sense in most contexts.

I seem to recall it's been discussed some time ago on the austin
group ML, but unfortunately can't seem to recall anything else
about it.

BTW, it looks like there's a bug in mksh:

$ mksh -c 'IFS=; x=abc; printf "<%s>\n" ${x#$*}' x a b | sed -n l
<\a\300a>$
$
$ mksh -c 'echo "$KSH_VERSION"'
@(#)MIRBSD KSH R50 2014/10/03

(pdksh 5.2.13 doesn't seem to be affected).

While we're at comparing ash and mksh.

POSIX requires word splitting be performed upon arithmetic
expansion.  Yes, that's stupid, even more stupid than the way
$*/$@ are handled in ksh, but that's the way it is.

dash is compliant in that case

$ dash -c 'IFS=2; echo $((11*11))'
1 1

But not mksh (and I'd praise it for doing the right thing here).

$ mksh -c 'IFS=2; echo $((11*11))'
121

nor zsh in sh emulation.

I won't blame you if you don't change mksh so as to be
compliant so long as you don't blame dash for "IFS=; $@" to
expand to one word only ;-)

-- 
Stephane


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141015112428.ga4...@chaz.gmail.com

Re: piece of mind (Re: Moderated posts?)

[The Wanderer]

On 10/14/2014 at 04:15 PM, Olav Vitters wrote:

> On Sun, Oct 12, 2014 at 06:18:01PM +0200, lee wrote:
> 
>> Considering that the users are Debians' priority, couldn't this
>> issue be a case in which significant concerns from/of the users
>> about an issue might initiate a GR?  Wouldn't it speak loudly for
>> Debian and its ways and for what it stands for, or used to stand
>> for, if it was established procedure that issues arising
>> significant concerns amongst the users can lead to a GR?
>> 
>> I'm sure we could find quite a few supporters for having a GR
>> amongst the users (here).  And after all, we're all kinda stuck in
>> the same boat.  A GR might have the potential to make the gap
>> between users and devs/maintainers a lot smaller.  Otherwise, this
>> gap will only continue to become wider and wider.
> 
> Debian is known for focussing a lot on focussing on quality.
> Upgrading from one version to the next is expected to be utterly
> smooth. Any bug encountered is exceptional.

Definitions of what constitutes "utterly smooth" may vary, however.


The "should upgrading from wheezy to jessie automatically switch the
init system to systemd, unless the admin has taken some sufficiently
clear action to prevent it?" question is one possible example. One side
of that debate seems to think that a properly smooth upgrade requires
that such an automatic switch take place (because otherwise the init
system doesn't get upgraded to what would be put in place by a new
install, so the upgrade can't be said to have actually completed);
another seems to think that a properly smooth upgrade requires that such
an automatic switch *not* take place (because of the chance of breaking
existing local configuration, among possibly other things).


For another example: some time ago, on debian-devel, the question arose
of whether it's reasonable to expect people to reboot promptly after
installing e.g. a new kernel, or a new init system. While of course you
can't expect to gain any functionality advantage from the
newly-installed software until the reboot in those cases, it still seems
reasonable to me to expect that no previously-existing functionality
will be *lost* in the window between such an upgrade and the next reboot.

However, at least one of the systemd Debian maintainers stated in that
discussion that while having a "keep going as normal and reboot at
leisure" scenario work smoothly would be nice, he does not consider it a
hard requirement. (The functionality at hand apparently included, but
was not necessarily limited to, power-management functionality - such as
the "reboot" button. I think that particular piece of functionality may
have been addressed since then, but the larger principle still exists.)

I think that for such a scenario to not work would place the upgrade
outside the bounds of what constitutes "utterly smooth", and I would
consider any such functionality loss to be a bug - quite possibly an RC
bug. The maintainer in question, at least, does not appear to think
that; he does appear to agree that it would be a bug, but a minor one at
best. Thus, definitions vary, Q.E.D..

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Determining, ad hoc, whether someone is a DD

[Ian Jackson]

Many of our lookup interfaces don't give out a clear indication of the
status of the person you are looking up.  Eg db.debian.org contains
DMs and DDs and the public lookup doesn't distinguish.
www.debian.org/devel/people lists maintainers, DMs and DDs without
distinction.  (This is contrary to the information on
https://wiki.debian.org/DebianDeveloper.)

AFAICT there are two ways right now to find out whether someone is a
DD from primary sources[1]:

 * Install debian-keyring from sid and hope that it is up to date
   enough.  This is a 51Mby download.  It involves having a sid
   chroot, or messing about downloading the .deb by hand.

 * Log into the ftpmaster mirror and ask whatever dak asks.  (I
   haven't actually checked whether this is in the dak database proper
   and if so where, but presumably it is somewhere accessible to dak.)
   This is accessible to DDs only and obviously not a documented
   interface.

We have this list of DMs:
  https://ftp-master.debian.org/dm.txt
linked to from here:
  https://ftp-master.debian.org/

Could/should we have an equivalent list of DDs published alongside the
list of DMs ?  If this seems like a good idea I will file a bug asking
for it.

Thanks,
Ian.

[1] I'm told that looking at db.d.o ldapsearch can help if you then
see whether the user has `gidNumber=800' or perhaps whether the user
has `objectClass=debianDeveloper' but there are rumours that the
latter is misleading.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21566.32351.180763.700...@chiark.greenend.org.uk

Re: piece of mind (Re: Moderated posts?)

[Thorsten Glaser]

On Mon, 13 Oct 2014, Joey Hess wrote:

> Only thing I don't understand is why so few votes for systemd-shim out
> of the group who has it installed.

Maybe noatime? That’s probably popular on desktops. “vote” does
not really say much, anyway.

bye,
//mirabilos
-- 
Sometimes they [people] care too much: pretty printers [and syntax highligh-
ting, d.A.] mechanically produce pretty output that accentuates irrelevant
detail in the program, which is as sensible as putting all the prepositions
in English text in bold font.   -- Rob Pike in "Notes on Programming in C"


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.11.1410151608550.30...@tglase.lan.tarent.de

Re: $*/$@/$IFS and Bourne vs Almquist vs Korn vs mksh

[Thorsten Glaser]

On Wed, 15 Oct 2014, Stephane Chazelas wrote:

> $ mksh -c 'IFS=; x=abc; printf "<%s>\n" ${x#$*}' x a b | sed -n l
> <\a\300a>$
> $

Interesting… but all shells diverge on this one.

tglase@tglase:~ $ bash -c 'IFS=; x=abc; printf "<%s>\n" ${x#$*}' x a b | sed -n 
l
$
tglase@tglase:~ $ dash -c 'IFS=; x=abc; printf "<%s>\n" ${x#$*}' x a b | sed -n 
l
$
$
tglase@tglase:~ $ ksh93 -c 'IFS=; x=abc; printf "<%s>\n" ${x#$*}' x a b | sed 
-n l
$
tglase@tglase:~ $ mksh -c 'IFS=; x=abc; printf "<%s>\n" ${x#$*}' x a b | sed -n 
l
<\a\300a>$
$
tglase@tglase:~ $ pdksh-5.2.14 -c 'IFS=; x=abc; printf "<%s>\n" ${x#$*}' x a b 
| sed -n l
$

Makes you wonder if ksh93 gets it right, or if bash/pdksh do.
But I agree that mksh’s output is just as broken as dash’s here.

> POSIX requires word splitting be performed upon arithmetic
> expansion.  Yes, that's stupid, even more stupid than the way
> $*/$@ are handled in ksh, but that's the way it is.
[…]
> But not mksh (and I'd praise it for doing the right thing here).
>
> $ mksh -c 'IFS=2; echo $((11*11))'
> 121

I’d praise it too, except, your mksh is too old. I was notified
of this POSIX requirement being unearthed, and changed the shell
to comply. (The requirement to parse $((010)) as 8 is worse IMO,
and only done if “set -o posix”.)

tglase@tglase:~ $ mksh -c 'IFS=2; echo $((11*11))'
1 1
tglase@tglase:~ $ mksh -c 'print $KSH_VERSION'
@(#)MIRBSD KSH R50 2014/10/07

Bugfixes to the shell to adhere more strictly to POSIX are frequent.
But this should have been in R50 already.

bye,
//mirabilos
-- 
Sometimes they [people] care too much: pretty printers [and syntax highligh-
ting, d.A.] mechanically produce pretty output that accentuates irrelevant
detail in the program, which is as sensible as putting all the prepositions
in English text in bold font.   -- Rob Pike in "Notes on Programming in C"


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.11.1410151614380.30...@tglase.lan.tarent.de

Re: Built-Using, again…

[Thorsten Glaser]

On Wed, 15 Oct 2014, Cyril Brulebois wrote:

> Thorsten Glaser  (2014-10-15):
> > Who are powerpc buildd admins, again?
> 
> Still listed at the same location since last time you asked:

Yeah, I tend to forget it.

>   https://www.debian.org/intro/organization

Ah wonderful, a set of 0 people. No surprise then.

bye,
//mirabilos
-- 
[16:04:33] bkix: "veni vidi violini"
[16:04:45] bkix: "ich kam, sah und vergeigte"...


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.11.1410151619280.30...@tglase.lan.tarent.de

[PATCH] link buildd admin mail template to organisational chart listing them

[Thorsten Glaser]

Signed-off-by: Thorsten Glaser 
---
 library.php | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/library.php b/library.php
index a5a0d8e..43e2c45 100644
--- a/library.php
+++ b/library.php
@@ -1432,7 +1432,7 @@ function html_footer_text($raw=false) {
   echo "
 Page generated on $date UTC
 Pages written by https://wiki.debian.org/MehdiDogguy\";>Mehdi 
Dogguy
-Architecture specific issues should be sent to \$a...@buildd.debian.org>
+Architecture specific issues should be sent to \$a...@buildd.debian.org>
 Service maintained by the wanna-build team debian-wb-t...@lists.debian.org>
 Download code with git: git clone 
https://buildd.debian.org/git/pgstatus.git
 
-- 
2.1.1


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20141015143858.4b6cc220...@tglase.lan.tarent.de

Re: Determining, ad hoc, whether someone is a DD

[Paul Wise]

On Wed, Oct 15, 2014 at 10:02 PM, Ian Jackson wrote:

> [1] I'm told that looking at db.d.o ldapsearch can help if you then
> see whether the user has `gidNumber=800' or perhaps whether the user
> has `objectClass=debianDeveloper' but there are rumours that the
> latter is misleading.

gidNumber is the way to distinguish between Debian members (800),
guest accounts (6) and role accounts (various) in db.d.o LDAP.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAKTje6Hnu78i=ijbtF_cZLgVDHqSt3D9=7tzqujzghvsok7...@mail.gmail.com

Re: Determining, ad hoc, whether someone is a DD

[Paul Wise]

On Wed, Oct 15, 2014 at 10:02 PM, Ian Jackson wrote:

> db.debian.org contains DMs and DDs

db.d.o does not contain DMs AFAIK, but it does have guest accounts and
indeed doesn't distinguish those. DSA have been working on a
replacement for our current interface and could use help with
improving it.

https://github.com/LucaFilipozzi/ud/

> www.debian.org/devel/people lists maintainers, DMs and DDs without
> distinction.

It in fact just lists people from Maintainers and Uploaders.

https://anonscm.debian.org/cgit/debwww/cron.git/tree/people_scripts/people.pl

> (This is contrary to the information on
> https://wiki.debian.org/DebianDeveloper.)

Clarified.

>  * Install debian-keyring from sid and hope that it is up to date
>enough.  This is a 51Mby download.  It involves having a sid
>chroot, or messing about downloading the .deb by hand.

I would suggest downloading the live keyrings via rsync instead:

http://keyring.debian.org/

> Could/should we have an equivalent list of DDs published alongside the
> list of DMs ?  If this seems like a good idea I will file a bug asking
> for it.

Seems like a good idea to me.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAKTje6E2ZDKtQtybDSijhuTP0_P-sdjAz3y=vbntfpuv+wx...@mail.gmail.com

Re: Built-Using, again…

[Paul Wise]

On Wed, Oct 15, 2014 at 10:20 PM, Thorsten Glaser wrote:
> On Wed, 15 Oct 2014, Cyril Brulebois wrote:
>>   https://www.debian.org/intro/organization
>
> Ah wonderful, a set of 0 people. No surprise then.

Unfortunately that page is maintained manually.

According to LDAP it appears to be wouter, he, pkern.

I searched for hosts with architecture powerpc and people with
supplementaryGid set to buildd@$hostname.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAKTje6G0C=su8zyjaykzd4ups53vev9qgkuifpmdrhdcvj1...@mail.gmail.com

Bug#765493: ITP: bifrost -- Intelligent self-learning whitelist-based web application firewall

[Joao Eriberto Mota Filho]

Package: wnpp
Severity: wishlist
Owner: Joao Eriberto Mota Filho 

* Package name: bifrost
  Version : 0.1.0-alpha
  Upstream Author : Jan Seidl 
* URL : https://github.com/jseidl/bifrost
* License : MIT
  Programming Lang: Python
  Description : Intelligent self-learning whitelist-based web application 
firewall

 This Web Application Firewall (WAF) uses its learning mode to gather a
 profile of the requested page. It analyzes and learns several parameters
 such as post fields, request/response content-size, response header count
 and size, file mimetypes and such to create a locked down whitelist to each
 page in each HTTP method provided.
 .
 This program is useful to avoid attacks against web applications in networks.
 These attacks can be SQL injection, remote command execution, arbitrary file
 upload, etc.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20141015152710.6163.65732.reportbug@scutum.darknet

Re: [OT] $*/$@/$IFS and Bourne vs Almquist vs Korn vs mksh

[Stephane Chazelas]

2014-10-15 16:19:00 +0200, Thorsten Glaser:
[...]
> tglase@tglase:~ $ dash -c 'IFS=; x=abc; printf "<%s>\n" ${x#$*}' x a b | sed 
> -n l
> $
> $
> tglase@tglase:~ $ ksh93 -c 'IFS=; x=abc; printf "<%s>\n" ${x#$*}' x a b | sed 
> -n l
> $
> tglase@tglase:~ $ mksh -c 'IFS=; x=abc; printf "<%s>\n" ${x#$*}' x a b | sed 
> -n l
> <\a\300a>$
> $
> tglase@tglase:~ $ pdksh-5.2.14 -c 'IFS=; x=abc; printf "<%s>\n" ${x#$*}' x a 
> b | sed -n l
> $
> 
> Makes you wonder if ksh93 gets it right, or if bash/pdksh do.
> But I agree that mksh’s output is just as broken as dash’s here.
[...]

The dash versions I have access to give the expected output
(same as your ksh93).

ksh93 has some other interesting bugs:

$ ksh -c 'IFS="*"; a=abcd; printf "<%s>\n" "$*" ${a##"$*"}' sh '' c
<*c>


bash and pdksh join the arguments with spaces. And there's
nothing in POSIX that allows them to do that.

But the problem is that that area is not covered by POSIX.

In the Bourne and Almquist shells, $* and $@ are normal
variables (except for $@ quoted in list contexts).

While for bash/ksh, they are array variables. POSIX fails to
pick a side here. They don't say that $* and $@ expansion are
not special other than that vague "expands to positional
arguments" which doesn't mean anything (and I can see dash has
just been updated so that unquoted $@ and $* expand to
positional arguments as separate words (still subject to
split+glob) in list context to match that vague requirement,
breaking consistency in the process).

And they don't say how those "arrays" are to be cast to scalars
when not in list context since they don't specify arrays in the
first place.

The non-list contexts include

a=$*
${a#$*}

case x in
  $a) ...;;
  "$a") ...
esac
${a#"$*"} # beware quotes also serve to cancel globs there

$(( $* ))
...

In any case, that's corner cases, not really ground for picking
one shell over the other for /bin/sh.

-- 
Stephane


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141015154529.ga4...@chaz.gmail.com

Re: Determining, ad hoc, whether someone is a DD

[Jonathan McDowell]

On Wed, Oct 15, 2014 at 03:02:07PM +0100, Ian Jackson wrote:
> Many of our lookup interfaces don't give out a clear indication of the
> status of the person you are looking up.  Eg db.debian.org contains
> DMs and DDs and the public lookup doesn't distinguish.
> www.debian.org/devel/people lists maintainers, DMs and DDs without
> distinction.  (This is contrary to the information on
> https://wiki.debian.org/DebianDeveloper.)
> 
> AFAICT there are two ways right now to find out whether someone is a
> DD from primary sources[1]:
> 
>  * Install debian-keyring from sid and hope that it is up to date
>enough.  This is a 51Mby download.  It involves having a sid
>chroot, or messing about downloading the .deb by hand.

If you want the version of the keyring the project infrastructure is
using then the canonical way to obtain it is:

 rsync -az --progress keyring.debian.org::keyrings/keyrings/ .

There is a sha512sums.txt file included which will be signed by myself,
gwolf or dkg.

To the main point of your email there is discussion about ensuring that
even DMs have usernames and I believe it would be a good idea for LDAP
to then have a separate group to indicate when someone is a DM vs a DD.

J.

-- 
Web [ "Scattered f***ing showers my ass." -- Noah  ]
site: http:// [  ]   Made by
www.earth.li/~noodles/  [  ] HuggieTag 0.0.24


signature.asc
Description: Digital signature

Bug#765509: ITP: python-flask-admin -- admin interface extension for Flask

[Arto Jantunen]

Package: wnpp
Severity: wishlist
Owner: Arto Jantunen 

* Package name: python-flask-admin
  Version : 1.0.8
  Upstream Author : Serge S. Koval 
* URL : https://github.com/mrjoes/flask-admin
* License : BSD
  Programming Lang: Python
  Description : admin interface extension for Flask

 Flask-Admin is a batteries-included, simple-to-use Flask extension that lets
 you add admin interfaces to Flask applications. It is inspired by the
 *django-admin* package, but implemented in such a way that the developer has
 total control of the look, feel and functionality of the resulting
 application.
 .
 Out-of-the-box, Flask-Admin plays nicely with various ORM's, including
 .
 - SQLAlchemy
 - MongoEngine
 - pymongo
 - Peewee


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141015173237.8969.88106.reportbug@tsunami

Re: Any news about Blends in tasks selection (Was: Debian Installer Jessie Beta 2 release)

[Bas Wijnen]

Hi,

On Wed, Oct 15, 2014 at 09:31:36AM +0200, Andreas Tille wrote:
> You belong to a majority if I might conclude from my experience.  I have
> no idea whether I should feel responsible for this but I'm fighting on
> several fronts like the extensive documentation[1] and countless
> talks[2] as well as trying to push newcomers into the topic by
> sponsering their packages[3].

Yes, I noticed.  Thanks for all that work!

> For the moment the way to install Blends is to use the plain Debian
> installer and afterwards install a bunch of metapackages.

Ah, and that's what you want to change now.  That sounds like a very
good idea.

> The lack of a missing installer for all other Blends is a frequently
> criticised problem and I personally think this should be fixed by the
> integration into the official boot cds since this fits to the nature
> of Blends which are a subset of Debian.

Yes, I agree.  For the documentation, I think the main thing that is
missing is "how to start and stop"; important for every documentation.
"Stopping" isn't really relevant in this case (but it doesn't hurt to
mention that the metapackage can be uninstalled).  But "To use a Blend,
you need to install its metapackage" would have clarified it for me.
Once it is possible, it would be very nice if "there is an option to do
this during system install" could be added to that.

>   - Blends are a way to advertise Debian in specific fields of interest
> I personally started from a point where I wanted to reach a status,
> that if somebody wonders what distribution to use for biology and
> medical care the natural answer should be "Use Debian"  We could
> easily reach this goal for other fields of interest if all our
> dedicated experts we had in Debian would work on this direction in
> their own field.

On occasion, I've needed a single-use system; something that boots up
into an application and that shuts down when that application exits.
(Having the full power of Debian in the background is a nice feature,
but mostly unused.)  For example, for dancing rehearsal I want the
instructors to be able to switch their computer on and have the sound
program start up without any interaction.  It isn't hard to set this up,
but if I want to tell other dancing instructors how to do this, it
requires more steps than I would like.  I've tried making custom live
CDs, with a special package that does these things.

Would this use case also be a reason for creating a personal blend?  Or
even an official one?  What would be the easiest way for people to
install a non-official blend?  Should I create my own installer?  Should
the installer be changed to allow entering a URL (for an external apt
source) before it presents the list of available blends?  (I think this
might be a good idea, but it shouldn't be in there by default; only when
the user selects "back" on the blend selection menu.  Or perhaps there
can be a button in that menu for opening the dialog, but if it's for
adding any apt repository, the blends dialog is not the right place for
it.)

> There might be additional apt sources but it is not only about apt
> sources.  For instance (as far as I'm informed) all packages in Debian
> Edu are inside Debian and there was just a need to change some
> configuration change of some *other* packages which conflicts with
> Debian policy (I'm pretty sure Jonas will respond in detail to this mail
> - so I save my time here B-)).

So it installs a package which changes configuration of other packages
when it is installed?  That sounds very ugly...  Isn't there a better
way to preconfigure a system?

> I hope I added some more points to this summary.

Yes, thank you.

> > Examples of the target audience would be useful.
> 
> H.  I had thought / hoped that this is documented in[5].

It is, but I think it's too much text and too far away.  It's good that
it's there, but I think it would be good to have on the first page
people are pointed to (which one is that anyway?  The one in the wiki?)
a one-line explanation that is understandable.  The definition of "Pure
Blend" on https://wiki.debian.org/DebianPureBlends is "a subset of
Debian that is configured to support a particular target group
out-of-the-box."  That does not give me enough information to know if I
should be interested enough to read any further.

Oh, and I have another question; this seems very similar to "tasks"; how
is it different?

> Enhancements / patches(source is in package source of blends source
> package) are always welcome.

I might write a patch, but knowing myself I probably don't get around to
actually do that.

> > I admit I didn't spend a lot of
> > time trying to find answers to these questions, but I think it shouldn't
> > require a large time investment.
> 
> Do you think I should add these answers to the Wiki page with the
> relevant links?

Yes, that would be good.  But it should be as short as possible; less
text is better.  However, currently it is 

Re: piece of mind (Re: Moderated posts?)

[Joey Hess]

Thorsten Glaser wrote:
> On Mon, 13 Oct 2014, Joey Hess wrote:
> 
> > Only thing I don't understand is why so few votes for systemd-shim out
> > of the group who has it installed.
> 
> Maybe noatime? That’s probably popular on desktops. “vote” does
> not really say much, anyway.

I doubt noatime has been popular for years, we have relatime.
And if it were, there should be a similar or larger gap between
the installed and vote lines for other packages, which is not the case.

systemd-shim getting pulled in on systems where it's not needed seems
the most reasonable explanation. Which leaves the number of shim users
quite small, compared with the number of systemd users.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Built-Using, again…

[Wouter Verhelst]

Hi Thorsten,

On Mon, Oct 13, 2014 at 12:05:21PM +0200, Thorsten Glaser wrote:
[...]
> from dak, because the version is neither in testing (yet or
> still) and not in unstable (any more) and so not known to
> dak. The buildd admins do not react on this and happily
> ignore eMails asking them, politely, to dist-upgrade their
> buildd chroots and restart the build (giveback), for days.
[...]
> Now, the package doesn’t migrate to testing because the
> powerpc binaries are missing. (There’s still the delay,
> but let’s ignore that for a moment.) And we can’t have
> rebuilds within jessie – which would, hopefully, be ACCEPTed
> by dak – either, as the source package is not in testing yet.

(with powerpc buildd admin hat on)

I saw your mail, and intend to act upon it, but haven't had the time
yet. I have a life, too.

Thanks for the understanding.

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141015154523.gd8...@grep.be

Re: what free software is about/and supporting nonfree?, maybe add to clause 5?

[Wouter Verhelst]

On Sun, Oct 12, 2014 at 08:26:04PM +0200, Bas Wijnen wrote:
> On Sun, Oct 12, 2014 at 02:07:09PM +0200, Wouter Verhelst wrote:
> > The FSF has a stated goal of wanting to eradicate all non-free software.
> > That's fine, that's their right, and if they manage to do that, more
> > power to them.
> 
> Debian has a stated goal of helping free software (SC#4).  That is a
> very similar goal.

Yes, absolutely. It follows that Debian and the FSF should be "friends",
as much as that is possible as organizations (to which the concept
doesn't really apply).

> Especially when you realize that non-free software
> hurts free software (by taking users from it, thus making it lose bug
> reports and making it less interesting to work on).

I don't think this is true. For instance, the availability of non-free
software can be a way to compel people who think they cannot live
without it to use try to use free software operating systems for the
first time. That helps free software.

There are more such things, but that's besides the point.

> The main difference is, that in Debian "free software" has to share its
> prioritized position with "our users".  And SC#5 makes it clear that we
> can help non-free software if our users require it.  However, if we have
> a choice, free software is the way to go.  The difference between us and
> the FSF on this really is only a detail.

I don't agree with that.

> More specifically, the difference is that when people require non-free
> software, the FSF says "No you don't, you should live without that
> feature until there is a free replacement" and we say "Oh alright, but
> only until we've made a free replacement".

I like this. I think it's a very good description of our respecive
positions.

I don't think the difference is a mere detail, though. It is a
difference between what is almost a dogmatic position on the one hand,
and something more pragmatic on the other.

> > I respect you wanting to prefer the (in my opinion) worse option on that
> > list, but please realize that not everyone shares that preference. In
> > that light, just going "ignoring your question, you said non free, which
> > is EV1L!!, you should fix that first and then come back" like you did[1]
> 
> Ehm, no.  He pointed out that this would be the best thing to do (which
> was the question).  Nobody said "don't come back until you've done it".

I did describe that as "hyperbole".

> > makes people feel rather unwelcome.
> 
> And that is something to avoid, of course.  Paul's mail didn't seem to
> be doing that, though.

Well, we'll just have to agree to disagree, then.

If I say "I want to do foo, how do I do that", and someone replies with
"no you don't, you want to do bar instead", I feel very much unwelcome;
or at the very least, misunderstood.

> > [1] I realize that's a bit of a hyperbole and that you certainly didn't
> > mean it that way. However, I do think that is what your answer will
> > result in people feeling.
> 
> I don't think so.  The exception is people who have been having this
> debate for a while.  But those have made their minds up already anyway,
> so them thinking that you are a zealot doesn't matter; they already
> thought so anyway.

Possibly. That's all idle discussion, however.


-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141015152954.gc8...@grep.be

Bug#765512: general: distrust old crypto algos and protocols perdefault

[Christoph Anton Mitterer]

Package: general
Severity: important
Tags: security


Hi.

Not sure if there is already some concentrated effort, but I think
there should be one, i.e.:


---
To disable crypto algorithms and protocols per default, which are
known to be no longer secure, across Debian.

And ideally, to default to securer versions where possible, e.g.
not using SHA1, or SHA256, if it makes no difference to use SHA512
or maybe in some time Keccak.
---


I see that some people may actually be forced to still use such old
algorithms for whatever reason, but at least per default programs
should no longer accept them and manual admin/user intervention
should be required to re-enable them.

Of course there are some clear exceptions as well, i.e. for a program
like jacksum (in the package of the same name) it makes not sense
to forbid md5 from being calculated.

Further, some programs use some crypto algorithms (especially hash
algos) in a not-so-much security related way.
But care should be taken, since often it's not obvious, whether
something is actually security relevant or not.
For git it's e.g. quite clear that it's use of SHA1 *is* security
relevant.
For mldonkey one might think "well they use it just as an ID".

For some packages there may be simply no alternative, at least
none that Debian (or anything else but upstream) could provide.
An example again would be git,... even if it would be decided one
day, that SHA1 is no longer enough for the way being used in git,
we of course cannot change this alone.
Another example, anything OpenPGP related is inherently bound to
SHA1 (at least in parts), and without a new standard, nothing can
be done about.


In many cases, the respective upstreams already have discussions
about phasing out old algorithms, like in gnupg there is right no
a discussion abot old v3 keys.
But often these upstreams react very slowly and/or only when they
really have no further choice.
Take Mozilla now with the Poodle attack... that SSLv3 is close to
be broken could be seen for years now,... but they left users
vulnerable for no really good reasons.
IIRC, per default they still have rc4 enabled, which is broken
and the argument "that some servers support nothing else" may be
true but it's still a bad one. What people want from https is
"secure" communications (as far as this is possible within the
current X.509/SSL/TLS model) and better no connection at all
than one that anybody can read.



I'm probly not the biggest crypto expert out there, but I guess
most people will agree that following algorithms should be
avoided:
- MD5 (or anything before)
- RC4
- DSA1 with 1024 bit only
- SSLv3 (of course v2 as well)
- depending on where it's used: CBC
- MtE and EaM MACs should be avoided

and ideally:
- SHA1 should be avoided as well, it's not yet broken, sure, but
  cracks can be seen
- probably RIPEMD160 should be avoided as well,... I'm not sure
  about it's latest status in cryptoanalysis, but being one of
  the niche algortihms is another danger
- where possible, new algorithms (e.g. AE ciphers) should be
  used per default, GCM and recently ED25519 ChaCha and Poly1305
  look promising
- I personally would probably try to avoid the NIST curves in ECC
- where possible prefer (or only allow) algos with PFS



Affected packages/programs (of course this is only a small excerpt):
- major browsers (FF, Chromium, konqueror[0])
  - disable SLLv3, anything with MD5 (this includes certificates)
and RC4
IMHO users are better of with failed connections than using any
of them
  - set safer preferred algorithm lists
  - do this before Mozilla/Google/etc. decide so only because they
already now about an upcoming hole which completely breaks an
algo which is already known to have issues
- smaller browsers (links, lynx, etc.)
  basically the same
- curl,... not sure what it actually does, but options only allow
  to force a given SSL/TLS versions, not to disallow some
- wget seems to even use SSLv2 per default? (see manpage
  --secure-protocol option)
- anything related to secure APT (apt, aptitude, etc.) should no
  longer trust MD5, and ideally SHA1 should be phased out as well
  actually I'd probably vote for a combination of
  SHA2-512 and SHA3-512 in which *both* are validated and if any
  of them fails it's considered to be failed.
- http servers should default to not offer SSLv3 at least, and
  ideally at least suggest people to restrict even more
- SSH
- anything IPsec
- the countles of Perl, Python, Ruby, etc. packages which can
  to https or TLS/SSL
- ...



As one can see, this is probably nothing on person or maintainer
can do alone...
Yet I feel far to often these years that I wake up from time to
time, reading in the news that one was using algos with known
issue till now for no good reasons.



Cheers,
Chris.


[0] Last time I checked Epiphany was still vulnerable to insecure
redirections and thus SSL/TLS is completely disfunctional there.


-- 
To UNSUBSCRIBE, email to debian-devel-requ..

Re: Built-Using, again…

[Andreas Barth]

* Thorsten Glaser (t.gla...@tarent.de) [141015 16:20]:
> On Wed, 15 Oct 2014, Cyril Brulebois wrote:
> 
> > Thorsten Glaser  (2014-10-15):
> > > Who are powerpc buildd admins, again?
> > 
> > Still listed at the same location since last time you asked:
> 
> Yeah, I tend to forget it.
> 
> >   https://www.debian.org/intro/organization
> 
> Ah wonderful, a set of 0 people. No surprise then.

Buildd administration — @buildd.debian.org 
lists a couple of people. And also a working mail address. Contacting
people via a role account is always prefered.

Alternativly you could send mail to debian-wb-t...@lists.debian.org to
reach all of the people (but as Wouter already responded I'm not going
to forward your mail).



Andi


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141015181424.gp20...@mails.so.argh.org

Re: Built-Using, again…

[Andreas Barth]

* Thorsten Glaser (t...@mirbsd.de) [141013 12:05]:
> sbuild/buildd runs apt-get update, but not apt-get *upgrade,
> before each build. But I assume this should not be changed
> either…
> 
> So we need either a technical, or a policy-ical, or a human,
> solution to this problem, right?

Or we just have to decide which fall-out is least ugly, and keep care
of that. Which is what we do.

So, if you notice a problem with your package, please contact either
$arch@buildd.d.o, or the wanna-build team. As documented e.g. at the
web page you were already pointed to multiple times. Usually the
response time is good, exceptions are however always possible.
Also the time waiting for the final architectures to build and upload
successfully doesn't count against the package re waiting time till
britney considers an package acceptable (i.e. if the final binary is
uploaded on day 9 of 10, the package could migrate on day 10 - same as
if all binary packages are uploaded on day 0 of 10).

However, complaining at d-devel is usual not the appropriate path to
get problems actually fixed.



Andi


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141015183032.gq20...@mails.so.argh.org

Re: Built-Using, again…

[Andreas Barth]

* Paul Wise (p...@debian.org) [141015 17:22]:
> [ powerpc buildd admins ]
> According to LDAP it appears to be wouter, he, pkern.

This list is incomplete. There are more people, especially there is a
group who is buildd admin on all buildds, and tends to fix problems if
they are known. (However, these are the people who currently get mails
to powerpc@buildd.d.o - but we all have a real life, so unless it's
really required to have something fixed at this moment, it's better to
give people a couple of days for fixing. In the other case, use an
appropriate way to contact the buildd admin group as such.)

However, similar as with "asking smart questions", it's here "asking
smart help". So if I e.g. get a long mail telling "this and that bad
happend etc etc", and at the very bottom a "you have a very outdated
chroot, please update it" it makes it less likley to happen as if I
get a mail "package $foo was rejected because the chroot on $machine
was outdated. Can you please upgrade the chroot, and re-schedule the
package". Even if only for the reason that on a quick glance the first
mails looks complicated whereas I could do the second while
half-asleeping.


Andi


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141015183941.gr20...@mails.so.argh.org

Bug#765512: general: distrust old crypto algos and protocols perdefault

[Joey Hess]

Christoph Anton Mitterer wrote:
> For git it's e.g. quite clear that it's use of SHA1 *is* security
> relevant.

I've talked about this with the git developers before, and while they
seemed to have some ideas for how to handle a conversion to a different
hash, they're not keen on doing it until forced by SHA1 being more
broken than it is now.

I think that's a pity, especially because they could be adding a more
secure hash to git now, and use both hashes, and avoid a massive flag
day later.

Anyway, Debian obviously cannot go it on its own and change the hash
used by git, we need git to be useful for the things people use git for.

Instead, it makes sense to adapt workflows that do not trust git hashes,
which mostly means making signed tags and commits, and checking the
signatures. This is something Debian could improve in many areas, I'm
sure.


In general, I think that Debian needs to identify upstreams that are
being proactive about dropping old crypto algos, and those that are not.
Major browsers, openssh upstream, etc are going to be more on top of
this than we are, and make better decisions. Web servers probably have
user pressure to keep old crypto available, in order to support broken
clients that some users care about, and Debian might be able to improve
the defaults in such cases.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Bug#765512: general: distrust old crypto algos and protocols perdefault

[Jonathan Dowland]

There are a number of mechanisms for proposing and tracking distro-wide
changes, such as release goals and DEPs in some cases. But this is not what the
general bug is for. Please choose something and then kindly close this bug.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141015192521.gb...@chew.redmars.org

Re: bash exorcism experiment ('bug' 762923 & 763012)

[Wouter Verhelst]

On Wed, Oct 15, 2014 at 10:10:00AM +0200, Marco d'Itri wrote:
> On Oct 15, Wouter Verhelst  wrote:
> > If you target posh, you target all shells that policy allows for --
> > including those that are smaller and/or faster than dash.
>
> Can you list some, and what benefits they would bring over dash?

No, mostly because I don't care enough.

But that's *also* not the point. The point is that we have a policy
which states particular things, and that you should follow that policy.
If you think policy is wrong, you're welcome to change it; doing so
really isn't hard, especially if your change is technically sound. In
the absense of any such change, however, you should either change your
shell script to be policy-compliant, or change your shebang to pick an
explicit shell rather than /bin/sh.

Not doing so is a bug, plain and simple.

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141015193509.ga24...@grep.be

Re: Any news about Blends in tasks selection (Was: Debian Installer Jessie Beta 2 release)

[Jonas Smedegaard]

Quoting Bas Wijnen (2014-10-15 19:49:32)
> On occasion, I've needed a single-use system; something that boots up 
> into an application and that shuts down when that application exits. 
> (Having the full power of Debian in the background is a nice feature, 
> but mostly unused.)  For example, for dancing rehearsal I want the 
> instructors to be able to switch their computer on and have the sound 
> program start up without any interaction.  It isn't hard to set this 
> up, but if I want to tell other dancing instructors how to do this, it 
> requires more steps than I would like.  I've tried making custom live 
> CDs, with a special package that does these things.
>
> Would this use case also be a reason for creating a personal blend?  
> Or even an official one?  What would be the easiest way for people to 
> install a non-official blend?  Should I create my own installer?  
> Should the installer be changed to allow entering a URL (for an 
> external apt source) before it presents the list of available blends?  
> (I think this might be a good idea, but it shouldn't be in there by 
> default; only when the user selects "back" on the blend selection 
> menu.  Or perhaps there can be a button in that menu for opening the 
> dialog, but if it's for adding any apt repository, the blends dialog 
> is not the right place for it.)

That sounds like an excellent idea for a Blend!

You raise a bunch of questions on how that idea should be implemented 
and work out in details - but that has is open for you as driver of a 
Blend to figure out.

If you do decide to start create above as a Blend, and would be 
interested in collaborating (with me), please do count me in!  I have 
fumbled with a few ideas in the past that seems to fit perfectly to 
above (e.g. a dead-simple videophone "PhoneHome" dialing a hardcoded 
number, or a party jukebox with a touch keyboard (no avoid spilling 
liquids into a real keyboard, or a gaming box to pacify visiting kids, 
or...).

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Bug#765512: general: distrust old crypto algos and protocols perdefault

[Christoph Anton Mitterer]

On Wed, 2014-10-15 at 20:25 +0100, Jonathan Dowland wrote: 
> There are a number of mechanisms for proposing and tracking distro-wide
> changes, such as release goals and DEPs in some cases. But this is not what 
> the
> general bug is for. Please choose something and then kindly close this bug.
Well a bug is at least something, where one has a central log of all
discussions... and where one can really keep track of...

The problem with release goals / DEP is, that there is a lot of talking
but in the end nothing might really happen.

Also, I think that supporting broken algorithms actually *is* a bug :)


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Bug#765512: general: distrust old crypto algos and protocols perdefault

[Christoph Anton Mitterer]

On Wed, 2014-10-15 at 15:18 -0400, Joey Hess wrote: 
> I've talked about this with the git developers before, and while they
> seemed to have some ideas for how to handle a conversion to a different
> hash, they're not keen on doing it until forced by SHA1 being more
> broken than it is now.
Well,... I guess one could foresee that this will sooner or later become
an issue, right after git came out :-(

Hopefully, they will make this generic in the future... and ideally
retain the old IDs as well (but not using them on verification), so that
textual references to old commit IDs can still be used.


> I think that's a pity, especially because they could be adding a more
> secure hash to git now, and use both hashes, and avoid a massive flag
> day later.
Yep,... and as you said,... they rather seem to want to wait till the
last minute... :(
Really sad, especially since it was always also pointed out to be such a
great security benefit of git...


> Anyway, Debian obviously cannot go it on its own and change the hash
> used by git, we need git to be useful for the things people use git for.
Sure,... which is why I've listed git as one of the examples where we
can't do much


> Instead, it makes sense to adapt workflows that do not trust git hashes,
> which mostly means making signed tags and commits, and checking the
> signatures. This is something Debian could improve in many areas, I'm
> sure.
Uhm... well maybe I misunderstand you somehow,... but just trusting on
some unverified hash alone was never enough as it never proved anything
but integrity (not authenticity).
So singing was always necessary and always will be, even with SHA3 or
anything even "better".


> In general, I think that Debian needs to identify upstreams that are
> being proactive about dropping old crypto algos, and those that are not.
Not sure if this alone is enough... but I also have no real clue on how
one should actually organise such a crypto consolidation...
Perhaps with a website, that tracks packages using crypto, marking which
known-to-be-vulnerable stuff they still use/allow, which
we-rather-want-to-avoid-it-even-if-not-yet-broken stuff they
use/allow... and what their defaults in terms of algos are

Right now the whole seems like a big haystack to me,... sure it's easy
to talk about the big browsers,... but finding all the countless small
programs/libs which do https/TLS/SSL/etc... some of them even ignoring
certificate validations per default...


> Major browsers, openssh upstream, etc are going to be more on top of
> this than we are, and make better decisions.
Aha,... well I can't sign that... just look at Mozilla, they default to
RC4 being still allowed though it's known to be broken for months now,
and known to have issues for even longer.
Until not so many versions ago, they even defaulted to still allow
unsafe TLS renegotiations, IIRC.


> Web servers probably have
> user pressure to keep old crypto available, in order to support broken
> clients that some users care about, and Debian might be able to improve
> the defaults in such cases.
IMHO the big ones like webservers and browsers, are actually "less" of
an issue:
I mean either you have a security conscious admin/user and then he will
probably know about the most important stuff in crypto... or you have
someone who doesn't care,... and well... these people often even don't
upgrade their stuff regularly.

I'm not saying that it wouldn't be great if we could ship with better
defaults (and disable broken/questionable stuff) there as well,... I
just mean that I'm far more scared on all the small packages and little
tools one often easily forgets about, that they may actually be a
critical point in security.


Cheers,
Chris. 


smime.p7s
Description: S/MIME cryptographic signature

Re: Bug#765512: general: distrust old crypto algos and protocols perdefault

[Russ Allbery]

Joey Hess  writes:

> In general, I think that Debian needs to identify upstreams that are
> being proactive about dropping old crypto algos, and those that are not.
> Major browsers, openssh upstream, etc are going to be more on top of
> this than we are, and make better decisions. Web servers probably have
> user pressure to keep old crypto available, in order to support broken
> clients that some users care about, and Debian might be able to improve
> the defaults in such cases.

+1.  This exactly.

For another example, upstream for both Heimdal and MIT Kerberos know very
well what the situation is with the RC4 use in the Kerberos protocol and
are making well-informed decisions based on compatibility with existing
clients, just as they did with DES (which is now disabled by default in
both and likely to be removed entirely in the near future).  I don't think
we're likely to add a lot of value by trying to jump into that process.

Where Debian may be able to help more is with the long tail of software
that doesn't have as active or involved upstreams and may not be tracking
this issue as closely as we are.  And, of course, making sure that our
compilation and configuration defaults are as secure as possible.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87vbnlaz0r@hope.eyrie.org

Re: Bug#765512: general: distrust old crypto algos and protocols perdefault

[Jonas Meurer]

Hey,

Am 15.10.2014 um 21:44 schrieb Christoph Anton Mitterer:
> On Wed, 2014-10-15 at 20:25 +0100, Jonathan Dowland wrote: 
>> There are a number of mechanisms for proposing and tracking distro-wide
>> changes, such as release goals and DEPs in some cases. But this is not what 
>> the
>> general bug is for. Please choose something and then kindly close this bug.
> Well a bug is at least something, where one has a central log of all
> discussions... and where one can really keep track of...
> 
> The problem with release goals / DEP is, that there is a lot of talking
> but in the end nothing might really happen.

While I appreciate your efforts to raise security-relevant topics within
the Debian distribution, I have to admit that exactly the same happens
to quite a few of your "meta-bugreports" as well. There's a lot of
discussion and a few changes here and there, but then the bugreport is
forgotten and nobody cares anymore.

If you feel like keeping track of those distro-wide changes, I think a
properly maintained wiki page is much more appropriate for that purpose.

> Also, I think that supporting broken algorithms actually *is* a bug :)

In most cases your claim is true, but in some cases there might be
reasons for keeping support for old/broken algorithms. General
statements like that one don't help too much. Instead, I suggest to file
individual bugreports against particular packages, ideally already with
suggestions/patches on how to fix them.

Cheers,
 jonas



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/543ed14d.1020...@freesources.org

Re: Bug#765512: general: distrust old crypto algos and protocols perdefault

[Jonathan Dowland]

On Wed, Oct 15, 2014 at 09:44:43PM +0200, Christoph Anton Mitterer wrote:
> Well a bug is at least something, where one has a central log of all
> discussions... and where one can really keep track of...

Only if people remember to copy it. And that's less likely to happen
when you start getting down to the nitty-gritty of changes to actual
packages. Those discussions are more likely to happen on more specific
bugs. It's also a lousy way of keeping track of the current state of
affairs. Just consider the recent mammoth tech-ctte bugs. It must have
been a herculean effort for the tech-ctte to keep track of what had
been considered and what had not. A wiki page would be a much better
way of keeping a summary in place. Something like

https://wiki.debian.org/ReproducibleBuilds

or

https://wiki.debian.org/DebianEdu/Status/Jessie

for good examples.

> The problem with release goals / DEP is, that there is a lot of talking
> but in the end nothing might really happen.

The DEP process, at least, has had some thought put into the design to
address that issue.

> Also, I think that supporting broken algorithms actually *is* a bug :)

Well, it's a meta-bug, of sorts; really it isn't a bug itself. There are
others, that could be theoretically filed and blocking information between
this one and those filed in the BTS. Without that, how would you otherwise
consider when this bug is "fixed"? You can't really leverage the excellent
versioning features of the BTS with the general package.

Another problem with the "general" package is, who is responsible? Are you
prepared to take responsibility to close this bug yourself? If it isn't a
release goal, there's no push to have it resolved in any particular time
frame. It could languish forever.

-- 
Jonathan Dowland


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141015203321.gb1...@chew.redmars.org

Re: Bug#765512: general: distrust old crypto algos and protocols perdefault

[Christoph Anton Mitterer]

On Wed, 2014-10-15 at 21:55 +0200, Jonas Meurer wrote: 
> While I appreciate your efforts to raise security-relevant topics within
> the Debian distribution, I have to admit that exactly the same happens
> to quite a few of your "meta-bugreports" as well. There's a lot of
> discussion and a few changes here and there, but then the bugreport is
> forgotten and nobody cares anymore.
Sure, Jonas, I know,... and basically nothing has changed,... or well
not much at least... and the same with the discussion about secure APT,
downgrade/blocking attacks, the stuff about package downloaders, etc..


I mean that's just the problem what I try to explain every time
again,... it won't just work if you have some lone knights trying to do
this on their own, given the vast number of packages and software
affected, it's rather something a larger group would need to do.
Or even better, having guidelines, set up by such expert group, and
maintainers of packages should need to check through them... just like
proper auditing works.

But here comes the difficult part:
It's usually not easy to get people into a security conscious thinking,
so one won't find many people fighting this quest along one's side.
In practise it's even worse,... not rarely you have to fight maintainers
like windmills, endless discussions about what can be considered enough
secure, or whether it's more important to have stuff just being
colourful™ and working out-of-the-box™, rather then secure.

And these are only the problem's to the point, when you may break
peoples' setups which actually should break, because they're highly
insecure.
That's just as with the SSLv3 thingy... Mozilla for sure would argue
"well we had to keep it that long for interoperability".

When you then come to actual technical issues, as there *may* be with my
request to considerably shorten the validity times for Release files...
it's even more difficult to get something going.
Of course the respective developers have their own projects they want to
follow, but of course it should also be clear that one single person
(like me) cannot easily get fully involved in dozens of complex projects
like APT (and the security stuff - at least when one wants to do it
right - usually requires deep knowledge).


So you're absolutely right, when you say that not much comes out,... but
I guess for a single person it's not easily possible to do more than
constantly pointing at such issues, trying to start organising efforts
and then helping along.


> If you feel like keeping track of those distro-wide changes, I think a
> properly maintained wiki page is much more appropriate for that purpose.
Well I had that once[0] ... but the problems above remains,... if there
aren't more people that jump on the train - especially the affected
maintainers - you drive into a dead end


> In most cases your claim is true, but in some cases there might be
> reasons for keeping support for old/broken algorithms.
And as I wrote, I fully agree,... I mean this is basically what Russ
said in the other post:

On Wed, 2014-10-15 at 12:55 -0700, Russ Allbery wrote:
>For another example, upstream for both Heimdal and MIT Kerberos know
>very well what the situation is with the RC4 use in the Kerberos
>protocol and are making well-informed decisions based on compatibility
>with existing clients

Okay what does that mean? AFAIU it means: well there are still so many
people with outdated software out there, we can't just disable RC4, even
if it's broken.

I see it a bit differently:
RC4 is broken. Full stop.
Therefore new versions clients and servers should per default not
use/enable/accept it.

Of course Russ is right, that this would cause interoperability
issues,... but IMHO that should be manually decided by the admins/users.
If an kerberos admin says "well I still want/need to provide/trust RC4"
he should manually need to enable in the configs.
Same for a user/client, the other way round.


So I'm not saying that old broken/algos should be thrown out
completely[1] - they should just not come into use without user/admin
intervention.


> I suggest to file
> individual bugreports against particular packages, ideally already with
> suggestions/patches on how to fix them.
Mhh... nah I don't agree here. Discussing that with every package
maintainer is actually what makes it impossible to ever finish... I
rather think there should be project wide guidelines how to deal with
such questions.
Nothing that needs to be cut in stone and where one cannot make
exceptions in valid cases.

If there was consensus on how we actually want to handle security (here
in the sense of cryto strength: strong, medium, weak, none) then it
makes sense to move to the next step an actually implement it.


But as we've just seen... people's views already differ too much here to
have a staring point: One says interoperability is important and one
musn't break working systems just for security... another one like me
says rather break stuff (and let pe

Re: Bug#765512: general: distrust old crypto algos and protocols perdefault

[Russ Allbery]

Christoph Anton Mitterer  writes:
> On Wed, 2014-10-15 at 12:55 -0700, Russ Allbery wrote:

>> For another example, upstream for both Heimdal and MIT Kerberos know
>> very well what the situation is with the RC4 use in the Kerberos
>> protocol and are making well-informed decisions based on compatibility
>> with existing clients

> Okay what does that mean? AFAIU it means: well there are still so many
> people with outdated software out there, we can't just disable RC4, even
> if it's broken.

> I see it a bit differently:
> RC4 is broken. Full stop.
> Therefore new versions clients and servers should per default not
> use/enable/accept it.

> Of course Russ is right, that this would cause interoperability
> issues,... but IMHO that should be manually decided by the admins/users.
> If an kerberos admin says "well I still want/need to provide/trust RC4"
> he should manually need to enable in the configs.  Same for a
> user/client, the other way round.

> So I'm not saying that old broken/algos should be thrown out
> completely[1] - they should just not come into use without user/admin
> intervention.

The approach that you are taking to this discussion is destroying my
desire and willingness to explain to you all of the nuance that you're
ignoring.  But, to try anyway: your view of RC4 is simplistic, and is
ignoring the fact that Kerberos uses RC4 considerably differently than how
SSL does.  Many of the SSL attacks on RC4 rely on the properties of HTTPS
and the nature of the data being encrypted, whereas Kerberos uses RC4 in a
much different mode.  There's a lot of discussion in the crypto community
about to what extent the same techniques carry over.

Disabling RC4 enctypes breaks interoperability with all Windows XP
systems.  That's clearly going to be the right thing to do soon, and both
MIT and Heimdal have future plans to do this, which they're coordinating
with support cycles and feedback from large sites.

It's unlikely that you're going to be able to make better cost/benefit
decisions about these things than well-informed upstreams for general use
cases.  Debian is targeted for general use cases.  If we were making a
security-hardened distribution that chooses security over interoperability
across the board, we may well want to make other decisions.

Security is not an end in and of itself.  People want to use their
computers to do things, not to just be secure.  Security is always a
tradeoff.  This is inherent in the nature of the work.  Different people
are going to want to make that tradeoff in different ways.  Debian can
help push the tradeoffs towards more secure software, but if we go too far
and just break things, people are going to re-enable insecure stuff and
not trust our defaults in the future.  That, in turn, can easily mean that
the deployed systems in the wild end up being *less* secure than if we
maintain users' trust in the defaults.  Debian, as a very large and
widely-used distribution, is necessarily going to be more conservative
than small and security-focused distributions whose users are much more
tolerant of aggressive decisions that break backward compatibility.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87r3y9aw3p@hope.eyrie.org

Bug#765512: general: distrust old crypto algos and protocols perdefault

[Florian Weimer]

* Christoph Anton Mitterer:

> Not sure if there is already some concentrated effort, but I think
> there should be one, i.e.:

Fedora is currently working on this:

  

However, it is an ongoing effort to make applications adhere to the
system defaults.  (In the past, cryptographic libraries had bad
defaults, so policy had to be put into application code.  Yuck.)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87zjcxawmf@mid.deneb.enyo.de

Re: piece of mind (Re: Moderated posts?)

[Adam Borowski]

On Wed, Oct 15, 2014 at 01:49:43PM -0400, Joey Hess wrote:
> Thorsten Glaser wrote:
> > On Mon, 13 Oct 2014, Joey Hess wrote:
> > 
> > > Only thing I don't understand is why so few votes for systemd-shim out
> > > of the group who has it installed.
> > 
> > Maybe noatime? That’s probably popular on desktops. “vote” does
> > not really say much, anyway.
> 
> I doubt noatime has been popular for years, we have relatime.

relatime is almost as broken as atime.  Among other reasons, on a typical
system it adds multiple gigabytes of unique data to every cow snapshot.
Thus if you want btrfs backups, noatime is a must.

> systemd-shim getting pulled in on systems where it's not needed seems
> the most reasonable explanation. Which leaves the number of shim users
> quite small, compared with the number of systemd users.

shim doesn't appear to work, at least for me.  To get basic functionality
like shutdown from GUI, suspend or mounting USB drives, I needed to
downgrade the whole Utopia stack to their last working versions.

-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141015220124.ga22...@angband.pl

Re: bash exorcism experiment ('bug' 762923 & 763012)

[Ian Jackson]

Wouter Verhelst writes ("Re: bash exorcism experiment ('bug' 762923 & 763012)"):
> But that's *also* not the point. The point is that we have a policy
> which states particular things, and that you should follow that policy.
> If you think policy is wrong, you're welcome to change it; doing so
> really isn't hard, especially if your change is technically sound. In
> the absense of any such change, however, you should either change your
> shell script to be policy-compliant, or change your shebang to pick an
> explicit shell rather than /bin/sh.

Actually, the problem is indeed in policy.  In its resolution of
#539158 the TC decided unanimously (but unfortunately slightly
implicitly) that printf ought to be provided by our /bin/sh.

Unfortunately the policy has not been properly clarified.  This leaves
us in the somewhat unsatisfactory situation where our real
compatibility requirement is de facto rather than de jure.

As the maintainer of a minority shell, Thorsten has the most interest
in regularising this.  Perhaps Thorsten would like to propose a
suitable policy wording (with a view to changing posh to match).

Obviously that wording ought to be consistent with the TC's decision
in #539158 - ie, it should specify printf as a builtin.

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21566.63207.526614.878...@chiark.greenend.org.uk

Re: Bug#765522: ITP: elixir -- Functional language for the Erlang VM

[Andrei POPESCU]

Control: reassign -1 wnpp
Control: severity -1 wishlist

On Jo, 16 oct 14, 00:12:10, Evgeny Golyshev wrote:
> Package: wnppSeverine: wishlist
> Owner: Evgeny Golyshev 
> 
> * Package name : elixir
> * Version  : 1.0.1
> * Upstream Author  : José Valim 
> * URL  : http://elixir-lang.org
> * License  : Apache-2.0
> * Programming Lang : Erlang, Elixir
> * Description  : Functional language for the Erlang VM
> Elixir is a dynamic, functional language designed for building scalable and 
> maintainable applications.
> Elixir leverages the Erlang VM, known for running low-latency, distributed 
> and fault-tolerant systems, while also being successfully used in web 
> development and the embedded software domain.
> 
> Regards,
> Evgeny Golyshev

-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature

Bug#765512: general: distrust old crypto algos and protocols perdefault

[Ian Jackson]

Joey Hess writes ("Bug#765512: general: distrust old crypto algos and protocols 
perdefault"):
> Instead, it makes sense to adapt workflows that do not trust git hashes,
> which mostly means making signed tags and commits, and checking the
> signatures. This is something Debian could improve in many areas, I'm
> sure.

The whole git content-addressable-object-store model relies utterly on
the hashes.  A signed tag is a (weirdly formatted) GPG-signed text
file (the tag) containing the sha1 hash of a text file (the commit)
containing the sha1 hash of a binary file (the tree object) containing
the sha1 hasshes of the actual files at the top level and of further
binary files (tree objects) containing further sha1 hashes of further
files and further tree objects.  All of these hashes are translated
into their preimiages by looking them up in the object store.

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21566.63851.340276.17...@chiark.greenend.org.uk

Re: Bug#765512: general: distrust old crypto algos and protocols perdefault

[brian m. carlson]

On Wed, Oct 15, 2014 at 11:47:07PM +0100, Ian Jackson wrote:
> Joey Hess writes ("Bug#765512: general: distrust old crypto algos and 
> protocols perdefault"):
> > Instead, it makes sense to adapt workflows that do not trust git hashes,
> > which mostly means making signed tags and commits, and checking the
> > signatures. This is something Debian could improve in many areas, I'm
> > sure.
> 
> The whole git content-addressable-object-store model relies utterly on
> the hashes.  A signed tag is a (weirdly formatted) GPG-signed text
> file (the tag) containing the sha1 hash of a text file (the commit)
> containing the sha1 hash of a binary file (the tree object) containing
> the sha1 hasshes of the actual files at the top level and of further
> binary files (tree objects) containing further sha1 hashes of further
> files and further tree objects.  All of these hashes are translated
> into their preimiages by looking them up in the object store.

I've expressed interest in the past for changing the hash algorithm in
Git, but the work to do so is significant.  It basically means
converting every place that has a hardcoded "unsigned char[20]" and
moving it to a struct (later, a union) that can be treated more or less
opaquely.

If someone is interested in working with me on this, please let me know
off-list, and I can provide more information about this.
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Bug#765512: general: distrust old crypto algos and protocols perdefault

[brian m. carlson]

On Wed, Oct 15, 2014 at 01:58:34PM -0700, Russ Allbery wrote:
> It's unlikely that you're going to be able to make better cost/benefit
> decisions about these things than well-informed upstreams for general use
> cases.  Debian is targeted for general use cases.  If we were making a
> security-hardened distribution that chooses security over interoperability
> across the board, we may well want to make other decisions.

Unfortunately, not all upstreams make good decisions.  OpenSSL ships
with a set of default ciphers that is completely insecure.  There is no
reason that every application using OpenSSL directly or indirectly[0]
should have to disable exportable ciphers, especially since almost
nobody uses them (nor wants to).  HIGH:MEDIUM:!aNULL is a better
default.

It's fine to defer to upstream where they have a history of good,
prudent decision making, but there are upstreams where that's clearly
not the case, and Debian should step in and ship software that doesn't
have security holes by default.

[0] Including virtually every Ruby script that uses HTTPS.
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Bug#765512: general: distrust old crypto algos and protocols perdefault

[Brian May]

On 16 October 2014 10:44, brian m. carlson 
wrote:

> Unfortunately, not all upstreams make good decisions.  OpenSSL ships
> with a set of default ciphers that is completely insecure.  There is no
> reason that every application using OpenSSL directly or indirectly[0]
> should have to disable exportable ciphers, especially since almost
> nobody uses them (nor wants to).  HIGH:MEDIUM:!aNULL is a better
> default.
>

What about security updates? Should Debian be releasing wheezy security
updates for browsers,  web servers, etc, that disable SSLv3 by default now
that SSLv3 is considered insecure?
-- 
Brian May 

Re: Bug#765512: general: distrust old crypto algos and protocols perdefault

[Christoph Anton Mitterer]

On Wed, 2014-10-15 at 13:58 -0700, Russ Allbery wrote: 
> The approach that you are taking to this discussion is destroying my
> desire and willingness to explain to you all of the nuance that you're
> ignoring.
Well I respect that you have another opinion on security, but I didn't
demand you to explain it to me (if you, as you say, don't like my
approach); admittedly I don't understand your security philosophy.

So what's wrong about my approach, apart from the paradigm "security
first"?

> your view of RC4 is simplistic, and is
> ignoring the fact that Kerberos uses RC4 considerably differently than how
> SSL does.  Many of the SSL attacks on RC4 rely on the properties of HTTPS
> and the nature of the data being encrypted, whereas Kerberos uses RC4 in a
> much different mode.  There's a lot of discussion in the crypto community
> about to what extent the same techniques carry over.
Sure, and the same is true for other algorithms or modes,... e.g. CBC
isn't unsafe per se.
But I guess you wouldn't call RC4 rock solid, would you? Well at least
all crypto folks and paper I know say something in the range from "don't
use it unless you really must" to "stop using it. now."

Of course it depends on how something is used, but I remember some time
ago, when the first attacks in SSL/TLS where found against CBC and the
padding issues, where people said "well, we all know it has it's issues,
but for SSL/TLS it's okay for now". How long did that hold?

And I don't think, that you really believe that this won't happen for
RC4 in other contexts, do you? And can you assure that the publicly
known cryptanalysis (which, as you say, may tell that RC4 is still okay
for krb) is having the last word? Who guarantees that there aren't any
organisations which can already easily break RC4 in the context of krb?

Of course one can always say "the NSA might already know how to break
it" but in case of RC4 we know about enough cracks that one can really
see that it's broken or that this point is at least knocking on the
door.


> Disabling RC4 enctypes breaks interoperability with all Windows XP
> systems.
Which is basically known to be coming to it's end of life for how many
years now... and in the meantime it's fully out of maintenance.

To be honest, I see no reason why to provide interoperability to an
insecure system, which users have known for years that the should act.
I rather feel that all other users, who did their homework or who aren't
using Windows or other incompatible clients at all, have to potentially
suffer from questionable defaults.

I understand you see this different, but I guess I may also have my own
opinion.


> That's clearly going to be the right thing to do soon
I just think it's a big problem if we always wait to the last minute.
That's what I've said in the initial post, that we rather should try to
move on to new algorithms proactively, even if there is not yet strict
need.

Moving onwards earlier is definitely better for security, even if you
have systems that use PFS. Because as practise shows, some people always
need very log to update their stuff, so not starting the migration in
the last minute is surely not the worst idea ever.


> and both
> MIT and Heimdal have future plans to do this, which they're coordinating
> with support cycles and feedback from large sites.
Well especially large sites should have probably had some people dealing
with security, which should have educated themselves about what they
should rather try to phase out.
So again I don't see the point why other users should potentially suffer
for some group being slow.
It's the same as with SSLv3 which was basically kept alive for some
years now just because of a minority still using a long dead browser -
and even if it would have been a large fraction, I still think it wasn't
fair for the others to live with it just because of those wo didn't move
on.

And as you mention large sites... at least sometimes I experienced
exactly the contrary.
I work for the LHC Computing Grid which is probably one (if not the) of
the largest distributed computing networks in the world... hundreds of
computing centres in a three Tier level hierarchy spread over all the
world with many thousands of scientists using its services and depending
on them for their work, thesises, etc..

As you said, often things go extremely slowly, but this also changes
completely if there is enough pressure or someone in charge simply says
"this is going to be done now, and all sites that don't comply are going
to be blacklisted".
Then new versions and even bigger changes are rolled out or activated in
few weeks or even days.



> It's unlikely that you're going to be able to make better cost/benefit
> decisions about these things than well-informed upstreams for general use
> cases.  Debian is targeted for general use cases.
Well as I've said several times before: I never said you should make it
impossible for people to use their older algorithms, if they need.
So what'

Re: Bug#765512: general: distrust old crypto algos and protocols perdefault

[Christoph Anton Mitterer]

On Thu, 2014-10-16 at 10:55 +1100, Brian May wrote: 
> What about security updates? Should Debian be releasing wheezy
> security updates for browsers,  web servers, etc, that disable SSLv3
> by default now that SSLv3 is considered insecure?
I'd guess that as soon as the respective vendor issues an update, the
security team from Debian will as usual be amongst the fastest to deploy
it :-)

My thread/bug though was more about how to deal with upstreams which
typically react too slow (well at least in my opinion :) ), and how to
keep track and deal with those, for which it's unknown whether upstream
takes an eye on crypto developments at all (e.g. the small libraries and
Perl/Python/etc. modules coming to my mind).


Cheers,
Chris. 


smime.p7s
Description: S/MIME cryptographic signature

Re: Bug#765512: general: distrust old crypto algos and protocols perdefault

[Christoph Anton Mitterer]

On Wed, 2014-10-15 at 23:44 +, brian m. carlson wrote: 
> HIGH:MEDIUM:!aNULL is a better default.
Still allows quite a number of combinations I probably wouldn't want to
entrust my data: RC4 stuff, DSS stuff, even some MD5 combination is in
the list.



smime.p7s
Description: S/MIME cryptographic signature

Re: Bug#765512: general: distrust old crypto algos and protocols perdefault

[Russ Allbery]

Christoph Anton Mitterer  writes:

> So what's wrong about my approach, apart from the paradigm "security
> first"?

It feels to me like you're spending lots of time telling other people
they're wrong and telling other people what they should be spending time
on, and then arguing with anyone who tells you that how you're going about
this isn't effective.  I find myself feeling frustrated and demoralized
rather than inspired to go do a bunch of work on something that you care
about.  That energy would be better put into making an actionable plan for
accomplishing something and then inviting people to help you make that
plan reality.

Your response to this message is another good example.  I pointed out that
everyone knows that RC4 needs to go away and that the Kerberos upstreams
have long-term plans for how to do that with a reasonable level of
disruption, and your response was paragraphs about how horrible RC4 is.
One, you're preaching to the choir, and two, I don't understand what
you're trying to accomplish by haranguing me about this.  You seem to have
entirely missed the point I was trying to get across, which is that many
upstreams are closely monitoring these issues and have a plan already,
and, when that's the case, their plan is probably better than something
Debian would come up with for their software.  (As Brian points out, this
isn't always the case, but that was partly Joey's point: we need to look
at whether upstream is engaged and has a plan, or whether they're ignoring
the problem or unaware.)

If you think upstream's plan is wrong, then you need to go argue with
*them* about that, not with us, unless upstream is *so* wrong that it
looks like we should just fork.  For good upstreams, such as the Kerberos
upstreams, they generally have crypto expertise in their team already and
can have a detailed discussion with you about exact threat models and
timelines for deprecating enctypes.  When that sort of expertise exists
upstream, I'm arguing that this is not the effective place to do
something.  Diverging from upstream has a rather significant cost,
particularly if we diverge from upstream and then *get it wrong*, which is
not outside the realm of possibility.

And then you go on to put words in my mouth, like this:

>> If we were making a security-hardened distribution that chooses
>> security over interoperability across the board, we may well want to
>> make other decisions.

> So you suggest against efforts of securing / hardening Debian? What
> about introduction of hardened compiler flags, apparmor, selinux, etc.?

> I personally don't think that hardening contradicts being a universal
> OS.

which is just frustrating.  I feel like you're turning my opinion into a
parody of what I said to make it easier to argue with.

Of course doing those sorts of things is consistent with being a universal
operating system.  But you'll notice that Debian did hardening roughly
around the same time (or even a bit later) than other major distributions,
which was nowhere near as fast as some of the security-focused
distributions did it.  And I'd love to have a solid and reliable SELinux
setup that we could just turn on, but *everyone* in the Linux distribution
space has found that extremely difficult to achieve.  My point is not
"don't do security stuff."  My point is "Debian is not going to be on the
cutting edge of disabling features in the name of security."

In other words, if your primary concern is security, Debian is always
going to be a little slow for you.  I don't think that's a problem, nor
does it imply that Debian should *never* push on security.  Just that
Debian is not a distribution that values security *above everything else*.
There are some distributions out there, including Debian derivatives, that
*do* take that approach, and I think that's very valuable for seeing just
how far one can push security measures and how much breaks.

Anyway, I'm afraid that this whole thread is going to be a waste of time,
so I'm going to stop responding here.  I just hate to see people wasting
their time writing long replies to threads like this that are going to go
nowhere because there's not an effective structure for accomplishing
anything, which is why I (and several other people here) are trying to
nudge you in the direction of something more productive and more likely to
succeed.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87d29sby0g@hope.eyrie.org

Re: Bug#765512: general: distrust old crypto algos and protocols perdefault

[Ian Jackson]

Christoph Anton Mitterer writes ("Re: Bug#765512: general: distrust old crypto 
algos and protocols perdefault"):
> So what's wrong about my approach, apart from the paradigm "security
> first"?

Firstly, I agree with everything Russ has said.

But secondly, I would worry that you're perhaps not paying enough
attention to the practicalities surrounding deployment of algorithms
and indeed security technologies more generally.

Your response to Russ about RC4 in Kerberos is an example.

Your comments about SSL are also concerning.  In some applications,
SSL is used opportunistically.  Indeed that's happening now to some of
Debian's web presence.  I often find myself fighting the modern trend
for ever-harder-to-get-past TLS warnings in web browsers.  Those
warnings and the associated hard-to-penetrate UI, which I am pretty
sure you support, are a marvellous example of the kind of thing which
can harm rather than improve security.  Making more things fail,
rather than work in a less-secure way, is often not an improvement.

The biggest threats to the security of our users are not sophisticated
attacks on elderly and half-broken cryptoalgorithms.  The biggest
threat is bugs.  After that comes the many failures to deploy _any_
security technology, because so much of it is hard to use, or to
manage and deploy.  Why is the whole world still using unencrypted
unauthenticated email ?

Now, where upstream have a bad set of defaults, I am totally in favour
of changing that in Debian.  That's not specific to security
questions.  But if we are going to change what upstream did, we should
be sure to know why the upstream package is the way that it is.  We
need to be aware of the security/compatibility tradeoffs - and often
it will be necessary to pick more compatibility over more security.

Ian.

PS: Here's an argument from my own authority: I have a PhD in computer
security; I worked fr many years in the computer security industry; I
have implemented cryptoalgorithms, protocols, and a great deal of
crypto-using application and security software.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21567.9773.962310.657...@chiark.greenend.org.uk

Re: Bug#765512: general: distrust old crypto algos and protocols perdefault

[Christoph Anton Mitterer]

On Wed, 2014-10-15 at 18:31 -0700, Russ Allbery wrote: 
> It feels to me like you're spending lots of time telling other people
> they're wrong and telling other people what they should be spending time
> on, and then arguing with anyone who tells you that how you're going about
> this isn't effective.
Well isn't that somehow the point of discussion and defending one's
opinions? Don't you just do the same?


> One, you're preaching to the choir, and two, I don't understand what
> you're trying to accomplish by haranguing me about this.  You seem to have
> entirely missed the point I was trying to get across, which is that many
> upstreams are closely monitoring these issues and have a plan already,
> and, when that's the case, their plan is probably better than something
> Debian would come up with for their software.  (As Brian points out, this
> isn't always the case, but that was partly Joey's point: we need to look
> at whether upstream is engaged and has a plan, or whether they're ignoring
> the problem or unaware.)
Uhm,... wasn't you who sparked the discussion about RC4 safety within
Kerberos?
I think originally I didn't mention kerberos at all.
So either I should have interpreted your following answers then as a
that's Russ' PoV and thus I'm expected to change my own opinion
accordingly, or I could take it as an invitation for discussion.
Or did I get anything wrong here?

My original point was merely that we have a lot of packages where the
situation seems completely unclear and other packages where upstream
makes bad decisions (e.g. Mozilla).
Now of course we can argue back and forth whether Mozilla's decisions
are good or not; I'd say they've waited well too long (and would
consider my point proven by POODLE), others would say it was right.
But I'd expect that neither you, nor Ian nor I'm the only one here who
studied computer science, mathematics and worked in the security areas
and cryptography, and probably we'll find people agreeing with your or
my position and even those with a completely different one.

Alas, a waste of time, for all of us - surely not what I've meant to
gain with #765512.





> If you think upstream's plan is wrong, then you need to go argue with
> *them* about that, not with us, unless upstream is *so* wrong that it
> looks like we should just fork.  For good upstreams, such as the Kerberos
> upstreams, they generally have crypto expertise in their team already and
> can have a detailed discussion with you about exact threat models and
> timelines for deprecating enctypes.  When that sort of expertise exists
> upstream, I'm arguing that this is not the effective place to do
> something.  Diverging from upstream has a rather significant cost,
> particularly if we diverge from upstream and then *get it wrong*, which is
> not outside the realm of possibility.


> And then you go on to put words in my mouth, like this:
> 
> >> If we were making a security-hardened distribution that chooses
> >> security over interoperability across the board, we may well want to
> >> make other decisions.
> 
> > So you suggest against efforts of securing / hardening Debian? What
> > about introduction of hardened compiler flags, apparmor, selinux, etc.?
> 
> > I personally don't think that hardening contradicts being a universal
> > OS.
> 
> which is just frustrating.  I feel like you're turning my opinion into a
> parody of what I said to make it easier to argue with.
Uhm no I really just wanted to understand what you were trying to say.
Your point was (AFAIU) that we're not a specialised distro focusing on
security, right? Next I understood, that we shouldn't place security
above interoperability.
That's why I've asked how that affects those other fields, since usually
all of them mean interoperability problems, or at least that things do
not longer work that straightforward out of the box.


> Of course doing those sorts of things is consistent with being a universal
> operating system.  But you'll notice that Debian did hardening roughly
> around the same time (or even a bit later) than other major distributions,
> which was nowhere near as fast as some of the security-focused
> distributions did it.  And I'd love to have a solid and reliable SELinux
> setup that we could just turn on, but *everyone* in the Linux distribution
> space has found that extremely difficult to achieve.  My point is not
> "don't do security stuff."  My point is "Debian is not going to be on the
> cutting edge of disabling features in the name of security."
I see, well that wasn't clear to me, at least from your previous points.


> In other words, if your primary concern is security, Debian is always
> going to be a little slow for you.  I don't think that's a problem, nor
> does it imply that Debian should *never* push on security.
But I guess you're aware, that an attacker usually doesn't wait till
software or a distro starts defending itself?


> I just hate to see people wasting
> their time writing long re

Bug#765512: marked as done (general: distrust old crypto algos and protocols perdefault)

[Debian Bug Tracking System]

Your message dated Thu, 16 Oct 2014 05:42:23 +0200
with message-id <1413430943.4706.42.ca...@scientia.net>
and subject line Re: Bug#765512: general: distrust old crypto algos and 
protocols perdefault
has caused the Debian Bug report #765512,
regarding general: distrust old crypto algos and protocols perdefault
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
765512: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765512
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: general
Severity: important
Tags: security


Hi.

Not sure if there is already some concentrated effort, but I think
there should be one, i.e.:


---
To disable crypto algorithms and protocols per default, which are
known to be no longer secure, across Debian.

And ideally, to default to securer versions where possible, e.g.
not using SHA1, or SHA256, if it makes no difference to use SHA512
or maybe in some time Keccak.
---


I see that some people may actually be forced to still use such old
algorithms for whatever reason, but at least per default programs
should no longer accept them and manual admin/user intervention
should be required to re-enable them.

Of course there are some clear exceptions as well, i.e. for a program
like jacksum (in the package of the same name) it makes not sense
to forbid md5 from being calculated.

Further, some programs use some crypto algorithms (especially hash
algos) in a not-so-much security related way.
But care should be taken, since often it's not obvious, whether
something is actually security relevant or not.
For git it's e.g. quite clear that it's use of SHA1 *is* security
relevant.
For mldonkey one might think "well they use it just as an ID".

For some packages there may be simply no alternative, at least
none that Debian (or anything else but upstream) could provide.
An example again would be git,... even if it would be decided one
day, that SHA1 is no longer enough for the way being used in git,
we of course cannot change this alone.
Another example, anything OpenPGP related is inherently bound to
SHA1 (at least in parts), and without a new standard, nothing can
be done about.


In many cases, the respective upstreams already have discussions
about phasing out old algorithms, like in gnupg there is right no
a discussion abot old v3 keys.
But often these upstreams react very slowly and/or only when they
really have no further choice.
Take Mozilla now with the Poodle attack... that SSLv3 is close to
be broken could be seen for years now,... but they left users
vulnerable for no really good reasons.
IIRC, per default they still have rc4 enabled, which is broken
and the argument "that some servers support nothing else" may be
true but it's still a bad one. What people want from https is
"secure" communications (as far as this is possible within the
current X.509/SSL/TLS model) and better no connection at all
than one that anybody can read.



I'm probly not the biggest crypto expert out there, but I guess
most people will agree that following algorithms should be
avoided:
- MD5 (or anything before)
- RC4
- DSA1 with 1024 bit only
- SSLv3 (of course v2 as well)
- depending on where it's used: CBC
- MtE and EaM MACs should be avoided

and ideally:
- SHA1 should be avoided as well, it's not yet broken, sure, but
  cracks can be seen
- probably RIPEMD160 should be avoided as well,... I'm not sure
  about it's latest status in cryptoanalysis, but being one of
  the niche algortihms is another danger
- where possible, new algorithms (e.g. AE ciphers) should be
  used per default, GCM and recently ED25519 ChaCha and Poly1305
  look promising
- I personally would probably try to avoid the NIST curves in ECC
- where possible prefer (or only allow) algos with PFS



Affected packages/programs (of course this is only a small excerpt):
- major browsers (FF, Chromium, konqueror[0])
  - disable SLLv3, anything with MD5 (this includes certificates)
and RC4
IMHO users are better of with failed connections than using any
of them
  - set safer preferred algorithm lists
  - do this before Mozilla/Google/etc. decide so only because they
already now about an upcoming hole which completely breaks an
algo which is already known to have issues
- smaller browsers (links, lynx, etc.)
  basically the same
- curl,... not sure what it actually does, but options only allow
  to force a given SSL/TLS versions, not to disallow some
- wget seems to even use SSLv2 per default? (see manpage
  --secure-protocol option)
- anything related to secure APT (apt, aptitude, etc.) should no
  lo

Re: Bug#765512: general: distrust old crypto algos and protocols perdefault

[Lars Wirzenius]

On Thu, Oct 16, 2014 at 05:42:23AM +0200, Christoph Anton Mitterer wrote:
> On Wed, 2014-10-15 at 18:31 -0700, Russ Allbery wrote: 
> > It feels to me like you're spending lots of time telling other people
> > they're wrong and telling other people what they should be spending time
> > on, and then arguing with anyone who tells you that how you're going about
> > this isn't effective.
> Well isn't that somehow the point of discussion and defending one's
> opinions?

Merely defending one's opinions is a recipe for long threads. A good,
productive discussion about Debian development requires understanding
other people's arguments, evaluating one's own point of view, and
adapting it to produce an improved synthesis position, and iterating
this a few times to end up with a consensus of an accurate mental
model of reality and a realistic plan of action, which can be worked
on, preferably by named people, who agree to it. Such a discussion
benefits greatly from empathy, sympathy, good will, and the lack of a
conviction that one is right.

-- 
http://gtdfh.branchable.com/ -- GTD for hackers
http://obnam.org/ -- HAVE YOU BACKED UP TODAY?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141016054147.gr21...@exolobe1.liw.fi

Re: Bug#765512: general: distrust old crypto algos and protocols perdefault

[Arto Jantunen]

Joey Hess  writes:
> In general, I think that Debian needs to identify upstreams that are
> being proactive about dropping old crypto algos, and those that are not.
> Major browsers, openssh upstream, etc are going to be more on top of
> this than we are, and make better decisions. Web servers probably have
> user pressure to keep old crypto available, in order to support broken
> clients that some users care about, and Debian might be able to improve
> the defaults in such cases.

I can't agree here about major browser vendors being an example of
proactively dropping old crypto algos. Browser vendors have strong
incentives to prioritise compatibility above everything else (if a user
can't access a website with your browser but can with a competitors
you've just lost a user). For security the same incentive doesn't really
exist, as when the vendors get caught with their pants down (as happened
here with the POODLE attack) all they need to say is "Well we didn't
know it was actually broken, and besides all the other browsers had it
enabled too".

As Russ said earlier in the thread security is always a compromise with
compatibility, but IMO the browser vendors end up making different
choices than we should. For example I have been running my browser for
over a year with SSLv3 disabled, and have only found one website that
doesn't work. There is no reason this couldn't have been disabled before
it was compromised. The same situation seems to be happening with RC4,
a practical attack needs to appear before it gets dropped.

-- 
Arto Jantunen


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/8761fksfvx@kirika.int.wmdata.fi

Re: Any news about Blends in tasks selection (Was: Debian Installer Jessie Beta 2 release)

[Andreas Tille]

Hi Bas,

On Wed, Oct 15, 2014 at 07:49:32PM +0200, Bas Wijnen wrote:
> 
> > For the moment the way to install Blends is to use the plain Debian
> > installer and afterwards install a bunch of metapackages.
> 
> Ah, and that's what you want to change now.  That sounds like a very
> good idea.

:-)
 
> > The lack of a missing installer for all other Blends is a frequently
> > criticised problem and I personally think this should be fixed by the
> > integration into the official boot cds since this fits to the nature
> > of Blends which are a subset of Debian.
> 
> Yes, I agree.  For the documentation, I think the main thing that is
> missing is "how to start and stop"; important for every documentation.
> "Stopping" isn't really relevant in this case (but it doesn't hurt to
> mention that the metapackage can be uninstalled).  But "To use a Blend,
> you need to install its metapackage" would have clarified it for me.
> Once it is possible, it would be very nice if "there is an option to do
> this during system install" could be added to that.

I'll put this on my todo list for 2014-11-05+x.
 
> On occasion, I've needed a single-use system; something that boots up
> into an application and that shuts down when that application exits.
> (Having the full power of Debian in the background is a nice feature,
> but mostly unused.)  For example, for dancing rehearsal I want the
> instructors to be able to switch their computer on and have the sound
> program start up without any interaction.  It isn't hard to set this up,
> but if I want to tell other dancing instructors how to do this, it
> requires more steps than I would like.  I've tried making custom live
> CDs, with a special package that does these things.
> 
> Would this use case also be a reason for creating a personal blend?  Or
> even an official one?

Jonas has answered this question.  I'd like to add that I'm no fan of
"personal" things since you spoil the idea of forming a team around the
idea.  I could perfectly imagine such a Blend and every specific
application is a separate "task" (in the Blends slang).  So you can
assemble those people with the goal to run one dedicated application.

> What would be the easiest way for people to
> install a non-official blend?  Should I create my own installer?  Should
> the installer be changed to allow entering a URL (for an external apt
> source) before it presents the list of available blends?  (I think this
> might be a good idea, but it shouldn't be in there by default; only when
> the user selects "back" on the blend selection menu.  Or perhaps there
> can be a button in that menu for opening the dialog, but if it's for
> adding any apt repository, the blends dialog is not the right place for
> it.)

Well, these are good questions.  They are abit hard to answer in a
situation when we are discussing about how to properly install the
currently existing Blends.
 
> > There might be additional apt sources but it is not only about apt
> > sources.  For instance (as far as I'm informed) all packages in Debian
> > Edu are inside Debian and there was just a need to change some
> > configuration change of some *other* packages which conflicts with
> > Debian policy (I'm pretty sure Jonas will respond in detail to this mail
> > - so I save my time here B-)).
> 
> So it installs a package which changes configuration of other packages
> when it is installed?  That sounds very ugly...  Isn't there a better
> way to preconfigure a system?

Yes.  The better way is to convince the single package maintainers.  The
longish discussion is in bug #311188.
 
> > H.  I had thought / hoped that this is documented in[5].
> 
> It is, but I think it's too much text and too far away.  It's good that
> it's there, but I think it would be good to have on the first page
> people are pointed to (which one is that anyway?  The one in the wiki?)
> a one-line explanation that is understandable.  The definition of "Pure
> Blend" on https://wiki.debian.org/DebianPureBlends is "a subset of
> Debian that is configured to support a particular target group
> out-of-the-box."  That does not give me enough information to know if I
> should be interested enough to read any further.

Also todo list for 2014-11-05+x.
 
> Oh, and I have another question; this seems very similar to "tasks"; how
> is it different?

Each Blend creates metapackages and a -tasks package to feed
tasksel.  Yes, we are using this term actively.  The difference is more
in the content that the tasks are specific for fields of interest but
the used technique is the same (which is intentional to enable
integration into the installer easily).
 
> > Enhancements / patches(source is in package source of blends source
> > package) are always welcome.
> 
> I might write a patch, but knowing myself I probably don't get around to
> actually do that.

... as always with documentation. :-)  The same applies to me to some
extend (and I'm not proud about this).
 
> > Do you think I should

Re: Bug#765512: general: distrust old crypto algos and protocols perdefault

[Jonathan Dowland]

On Thu, Oct 16, 2014 at 05:42:23AM +0200, Christoph Anton Mitterer wrote:
> On Wed, 2014-10-15 at 18:31 -0700, Russ Allbery wrote: 
> > It feels to me like you're spending lots of time telling other people
> > they're wrong and telling other people what they should be spending time
> > on, and then arguing with anyone who tells you that how you're going about
> > this isn't effective.
> Well isn't that somehow the point of discussion and defending one's
> opinions? Don't you just do the same?

There's no point having an argument unless you are prepared to have *your*
opinion changed.

I work for a University Computing Science department which has a research group
dedicated to Security research. They have a fair amount of success and there
are some very bright people in the group. My former boss, the Head of School,
originally set up the security group. We discuss these issues from time to
time.  He told me that one of the biggest problems they have with new
researchers is getting them to understand that security in the real world is a
matter of compromise. A lot of researchers come in with an attitude quite like
yours: absolutist. This is either insecure and must not be used in any
circumstances ever, or it's secure. The problem is this simply doesn't work,
for many reasons including the ones that Russ has done an excellent job of
explaining. The clients of the research group, including some large companies
and government departments with acronyms for names, know this. The good science
that comes out recognises this.

>From one of your other posts you make it quite clear that you appreciate the
practical difficulties of trying to get any distro-wide change made in Debian:
buy-in. If you want to see security in Debian improved; that's where your
efforts need to go, towards seeking buy-in. Read and carefully consider the
advice people have given you here regarding your approach, using things like
release goals, gaining consensus, altering your argument style, etc., if you
want any hope of achieving your ultimate goals.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141016065249.gc10...@chew.redmars.org