date:20141002

Hi

On Thu, Oct 2, 2014 at 4:56 PM, Reindl Harald  wrote:

> then that paragraph refer to Shellshock was not really appropriate without
> make really clear that this is not a panic reaction in context of already
> fixed bash bugs
>

I didn't think one would assume it is just a panic reaction if they read
the links I provided
in the first mail or when I mentioned that Ubuntu/Debian have switched
years back before any security issues but you aren't the only person to
assume that so I guess that didn't work out as well as I had hoped.  So
again,  I was using the security discussion as a jump start point.  Not
justification for the change itself.

Rahul
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell


Am 02.10.2014 um 22:45 schrieb Rahul Sundaram:
> On Thu, Oct 2, 2014 at 11:57 AM, Reindl Harald wrote:
> 
> because the conclusion that dash is not vulerable for
> other things is invalid
> 
> 
> I am afraid there was no such conclusions.  To acknowledge known bugs in bash 
> doesn't require anyone to conclude that dash doesn't have bugs

then that paragraph refer to Shellshock was not really appropriate without
make really clear that this is not a panic reaction in context of already
fixed bash bugs

it's sadly a common reaction if somewhere critical bugs where fixed try
to migrate to something else instead take a breath and consider that
the currently used one has now more focus than ever before and got more
attention from security specialists while the suggested replacement
might not

> Since the recent Shellshock aka Bashdoor vulnerability, there have been some 
> discussions about more distributions
> switching over (http://lwn.net/SubscriberLink/614218/019d9a52b0eaae3d/) and I 
> was wondering whether it is worth
> considering for Fedora?  FWIW, both dash and mksh is already packaged in 
> Fedora.

as already said:

also don't forget that currently a lot of people look into
bash in security context because of the things happened
short ago and it's wide use

besides that the known issues are fixed it could go easily
in the wrong direction switch to something different which
may also have it's own issues nobody cared until now and
has less focus in security context than bash now has



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell

Hi

On Thu, Oct 2, 2014 at 11:57 AM, Reindl Harald  wrote:

>
> because the conclusion that dash is not vulerable for
> other things is invalid
>

I am afraid there was no such conclusions.  To acknowledge known bugs in
bash doesn't require anyone to conclude that dash doesn't have bugs.

Rahul
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell

2014-10-02 Thread Ian Malone

On 2 October 2014 13:59, Chris Adams  wrote:
> Once upon a time, Lennart Poettering  said:

>
>> In general, I am pretty sure that except a couple of programming
>> language or UNIX aficionades very few people can actually correctly
>> separate bashisms from true bourneshellisms.
>
> It isn't that hard.

Anyone who has to write things that work on Ubuntu too for a start.
Really if you don't know what the extensions are you probably don't
need bash.

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell

2014-10-02 Thread Ian Malone

On 2 October 2014 17:13, Ralf Corsepius  wrote:
> On 10/02/2014 03:07 PM, Rahul Sundaram wrote:
>>
>> Hi
>>
>> On Thu, Oct 2, 2014 at 8:59 AM, Chris Adams wrote:
>>
>>
>> If that's the case, why do we have the /bin/sh symlink?  Just remove
>> it
>> and make the bash dependency explicit (so everything has to call
>> /bin/bash).
>>
>>
>> I understand this is a rherotical argument but the symlink exists
>> because it is required by things like system()
>
>
> No. /bin/sh is supposed to be a POSIX-compatible shell.
>
> I.e. scripts using "#!/bin/sh" shebang rely upon being interpreted
> POSIX-correctly and not to use any feature diverging from POSIX.
>
>
> As bash implements a superset of POSIX, it changes its behavior to a more
> POSIX-compliant behavior depending upon the name it is being invoked.
>

More posix compliant maybe, but still providing extensions. Otherwise
changing sh to another posix compliant shell would not cause people to
worry about /bin/sh scripts that would be broken by the change.

Whether bash or dash is more secure (and don't discount the fact that
debian and ubuntu mean there is effort going into dash), it's not a
great argument that /bin/sh should be bash to support scripts that
incorrectly use sh when they mean bash. From the point of view of
specifying dependencies, interoperability, even potentially security
auditing, if it needs bash it should specify bash. This makes sense
when you consider:
1. shellshock. A temporary workaround if /sh could be changed to a
different shell without breaking things would have been to do that
until patches came out. This applies whatever the default shell is.
2. Lightweight. It may make sense to change to dash by default, it
might not, but if sh means sh then people building minimal systems can
make that choice themselves and easily see (by grepping /bin/bash)
whether they're going to hit a problem. Applies for something like ash
or other alternatives too.
3. Portability. BSD, Debian, Ubuntu don't use bash. It really is the
case that there is still an API for sh and it's not bash.

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell

Hi

On Thu, Oct 2, 2014 at 11:59 AM, Tom Rivers wrote:

> You know, you could've simply replied to my original take on your
> self-described opportunistic proposal with something like, "No, Tom, I'm
> not just making this proposal because of Shellshock.  I really think there
> are some merits to dash
>

By the time you replied implying that I was pushing for us to abandon bash
or whatever, the conversation had already moved forward quite a bit and I
didn't see the point of repeating it again just for you.   Instead you went
back to insisting that security is somehow my original point when it
wasn't.

Rahul
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell


Am 02.10.2014 um 19:08 schrieb Bruno Wolff III:
> On Thu, Oct 02, 2014 at 13:05:27 -0400,
>  Matthew Miller  wrote:
>>
>> For the case of arbitrary variables (like USER_AGENT), the problem is
>> closed, because now only variables prefixed BASH_FUNC_ and with a suffix of
>> () in our current patch or %% upstream are scanned for function definitions.
> 
> Thanks for the update. I had read something about that change, 
> but didn't know it was done upstream and in Fedora

also don't forget that currently a lot of people look into
bash in security context because of the things happened
short ago and it's wide use

besides that the known issues are fixed it could go easily
in the wrong direction switch to something different which
may also have it's own issues nobody cared until now and
has less focus in security context than bash now has



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell

2014-10-02 Thread Bruno Wolff III


On Thu, Oct 02, 2014 at 13:05:27 -0400,
 Matthew Miller  wrote:


For the case of arbitrary variables (like USER_AGENT), the problem is
closed, because now only variables prefixed BASH_FUNC_ and with a suffix of
() in our current patch or %% upstream are scanned for function definitions.


Thanks for the update. I had read something about that change, but didn't 
know it was done upstream and in Fedora.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell

On Thu, Oct 02, 2014 at 11:22:18AM -0500, Bruno Wolff III wrote:
> I think the disconnect there was that people assumed that as long as
> you controlled which environment variables (by name) were passed you
> were OK. It was assumed that the values weren't processed outside of
> what you explicitly did.

Agreed.

> Unless the defining functions in environment values feature is
> disabled, this expectation is still broken, regardless of the parser
> fix. And I wouldn't be surprised if more issues come up in the
> future because of it.

For the case of arbitrary variables (like USER_AGENT), the problem is
closed, because now only variables prefixed BASH_FUNC_ and with a suffix of
() in our current patch or %% upstream are scanned for function definitions.


-- 
Matthew Miller

Fedora Project Leader
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal: Increasing application icon sizes to 64px

On Thu, Oct 02, 2014 at 11:34:18AM -0400, Rahul Sundaram wrote:
> I don't think anyone misunderstood that you have trouble disagreeing
> without also being insulting.   You are pushing off people who might
> otherwise be sympathetic to your perspective by constantly engaging in a
> discussion the way you do it.  Please stop.

Rahul, I read Harald's statement in the way he says it was intended here
too, but, Harald, I can see how it could easily be misinterpreted. Please,
everyone, be extra aware that when we're communicating in e-mail, tone,
jokes, sarcasm, and hyperbole misfire more often than not. (And, as we've
seen, tend to escalate into a horrible mess.)

-- 
Matthew Miller

Fedora Project Leader
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell

2014-10-02 Thread Zdenek Kabelac


Dne 2.10.2014 v 18:00 Haïkel napsal(a):

2014-10-02 17:56 GMT+02:00 Tomasz Torcz :


   Also it will reduce differences between Linux distribution. And take us
closed to what majority (Ubuntu and Debian) does.



I don't see the point, now that we use systemd ...
Besides, even on Debian/Ubuntu, Bash is still the most popular script
shell interpreter, having two shell in memory would be a regression.



It's really fun read such arguments.

So now I can see systemd-journal - eats over 8M of RAM (compared with 2M for 
rsyslog) it's wasting CPU doing useless jobs for 95% of users - now I'd call 
this a major regression.


Every bash eats around 4M of resident memory.

Compared with less then 0.8M for dash.

Now - I'm not advocating for switching to dash as default - not at all - I'm 
well aware how bashism spread everywhere.


I'd rather see fixed and improved bash with reduce memory footprint.

Just please STOP using those senseless  arguments...

Zdenek
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell

Hi

On Thu, Oct 2, 2014 at 12:13 PM, Ralf Corsepius  wrote:

No. /bin/sh is supposed to be a POSIX-compatible shell.
>

Right.  This is what I meant.  We can't just remove /bin/sh completely and
require users to always use dash or bash explicitly.  Whether it is a
symlink and what precisely it points to is a implementation detail as long
it is POSIX compatible

Rahul
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal: Increasing application icon sizes to 64px

Hi

On Thu, Oct 2, 2014 at 12:14 PM, Reindl Harald  wrote:

> which would be in fact more a reason to start realize that
> people are different in how they express things and not all
> is that insulting meant as it could be taken
>

https://fedoraproject.org/code-of-conduct

Please read the above link carefully and understand that this is a public
forum with certain expectations on how you express yourself.  Using words
such as "clown" and "idiot" on a regular basis is insulting. You can try to
shift the responsibility to others but the end result is you will be
moderated again and have trouble providing the feedback or worse yet
ignored entirely.

Rahul
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Base] Base Design WG agenda meeting 03 October 2014 15:00 UTC on #fedora-meeting

2014-10-02 Thread Phil Knirsch

Unfortunately tomorrow is a public holiday in Germany, but if someone 
else from the WG would run the meeting i've put together a proposed 
agenda for tomorrow to give a few updates:


Agenda:
 - Update buildrequires cleanup work (davids)
 - Update Alpha base image
 - Open Floor

Thanks & regards, Phil

--
Philipp Knirsch  | Tel.:  +49-711-96437-470
Manager Core Services| Fax.:  +49-711-96437-111
Red Hat GmbH | Email: Phil Knirsch 
Wankelstrasse 5  | Web:   http://www.redhat.com/
D-70563 Stuttgart, Germany
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell

2014-10-02 Thread Bruno Wolff III


On Thu, Oct 02, 2014 at 11:59:54 -0400,
 Miloslav Trmač  wrote:


As I said in the snipped part, anyone able to submit arbitrary input to a shell 
can already cause it to do arbitrary things. The parser bugs do not give the 
attacker anything they don’t already have, so they are not security-relevant. 
So we are back to the philosophical discussion about where is the vulnerability 
in putting untrusted data into the environment.


I think the disconnect there was that people assumed that as long as 
you controlled which environment variables (by name) were passed you 
were OK. It was assumed that the values weren't processed outside 
of what you explicitly did.


Unless the defining functions in environment values feature is disabled, 
this expectation is still broken, regardless of the parser fix. And I 
wouldn't be surprised if more issues come up in the future because of it.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell


On 10/02/2014 03:07 PM, Rahul Sundaram wrote:

Hi

On Thu, Oct 2, 2014 at 8:59 AM, Chris Adams wrote:


If that's the case, why do we have the /bin/sh symlink?  Just remove it
and make the bash dependency explicit (so everything has to call
/bin/bash).


I understand this is a rherotical argument but the symlink exists
because it is required by things like system()


No. /bin/sh is supposed to be a POSIX-compatible shell.

I.e. scripts using "#!/bin/sh" shebang rely upon being interpreted 
POSIX-correctly and not to use any feature diverging from POSIX.



As bash implements a superset of POSIX, it changes its behavior to a 
more POSIX-compliant behavior depending upon the name it is being invoked.



AFAIK, dash doesn't seem to have such a difference in behavior built-in. 
It always seems to be using a dash-specific sh-extensions.

From man dash:
"The current version of dash is in the process of being changed to 
conform with the POSIX 1003.2 and 1003.2a specifications for the shell. 
 This version has many features which make it appear similar in some 
respects to the Korn shell, but it is not a Korn shell clone (see 
ksh(1)). Only features designated by POSIX, plus a few Berkeley 
extensions, are being incorporated into this shell."


Ralf


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal: Increasing application icon sizes to 64px


Am 02.10.2014 um 18:04 schrieb Rahul Sundaram:
> On Thu, Oct 2, 2014 at 11:44 AM, Reindl Harald wrote:
> 
> i doubt that you people are that
> hypersensitive about every single word in real life too 
> 
> People wouldn't say this if it was the first time you wrote 
> something like this

which would be in fact more a reason to start realize that
people are different in how they express things and not all
is that insulting meant as it could be taken

> "or apps that haven't had an upstream release in 5 years"
> is part of the mail i responded to *word by word* - no idea
> where that leaves space for interpretation independent how
> often quotes are stripped to lose context
> 
> You would know the context better if you had read the link that was right 
> next to those words

it's a useless dicussion, it it is not that way than
it should not be written that way and only the link
placed to avoid confusion

so what - mistakes und misunderstanding happen on all sides - that's life



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal: Increasing application icon sizes to 64px

Hi

On Thu, Oct 2, 2014 at 11:44 AM, Reindl Harald  wrote:

>  i doubt that you people are that
> hypersensitive about every single word in real life too
>

People wouldn't say this if it was the first time you wrote something like
this.  Also since you asked, I am usually *far* more curt generally to
people in real life because I know them better but I go out of my way to
avoid doing that here precisely because online communication is already
devoid of lot of things including body language without adding random
insults into the mix.

"or apps that haven't had an upstream release in 5 years"
> is part of the mail i responded to *word by word* - no idea
> where that leaves space for interpretation independent how
> often quotes are stripped to lose context
>

You would know the context better if you had read the link that was right
next to those words.

Rahul
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell

2014-10-02 Thread Jakub Jelinek

On Thu, Oct 02, 2014 at 05:56:17PM +0200, Tomasz Torcz wrote:
>   Also it will reduce differences between Linux distribution. And take us
> closed to what majority (Ubuntu and Debian) does.

We don't need to follow Ubuntu or Debian in every not-so-smart decision they
make, we haven't followed them with the multiarch ugliness, I hope we don't
follow them in this either.  Security risks aren't primarily about the size
of codebase, but about attention to detail by the maintainers, which doesn't
look something dash excells in.

Jakub
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Go packaging

2014-10-02 Thread Vincent Batts


On 30/09/14 08:46 +0100, Richard W.M. Jones wrote:

How does gccgo affect the packaging of libraries?


The libraries may have support for one or more versions of the go API,
or exclusively one version. Since the gccgo support is usually an API
version or so behind, this compatibility would need to be considered.
Also, many libraries provide unit test files (*_test.go source) that are
tested using `go test` traditionally. Perhaps it is possible to test
them using only gccgo. I had never tried, but just did the following:
```
vbatts@noyee ~/huff (master) $ go test -c -x -compiler gccgo
WORK=/tmp/go-build256629732
mkdir -p $WORK/_/home/vbatts/huff/_test/_/home/vbatts/
mkdir -p $WORK/_/home/vbatts/huff/_test/
cd /home/vbatts/huff
gccgo -I $WORK -c -g -m64 -fgo-pkgpath=_/home/vbatts/huff 
-fgo-relative-import-path=_/home/vbatts/huff -o 
$WORK/_/home/vbatts/huff/_test/huff.o ./huffman.go ./words.go ./huffman_test.go 
./words_test.go
ar cru $WORK/_/home/vbatts/huff/_test/_/home/vbatts/libhuff.a 
$WORK/_/home/vbatts/huff/_test/huff.o
cd $WORK/_/home/vbatts/huff/_test
gccgo -I . -I $WORK -c -g -m64 -o ./main.o ./_testmain.go
ar cru ./main.a ./main.o
cd .
gccgo -o $WORK/_/home/vbatts/huff/_test/huff.test 
$WORK/_/home/vbatts/huff/_test/main.o -Wl,-( -m64 
$WORK/_/home/vbatts/huff/_test/_/home/vbatts/libhuff.a -Wl,-)
mkdir -p /home/vbatts/huff/
cp $WORK/_/home/vbatts/huff/_test/huff.test /home/vbatts/huff/huff.test
vbatts@noyee ~/huff (master) $ ./huff.test 
PASS

```

Perhaps an rpm macro could wrap this?



pgp1rkJK2qpOy.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell

2014-10-02 Thread Haïkel

2014-10-02 17:56 GMT+02:00 Tomasz Torcz :
>
>   Also it will reduce differences between Linux distribution. And take us
> closed to what majority (Ubuntu and Debian) does.
>

I don't see the point, now that we use systemd ...
Besides, even on Debian/Ubuntu, Bash is still the most popular script
shell interpreter, having two shell in memory would be a regression.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell

2014-10-02 Thread Miloslav Trmač

> The expected security improvement is essentially nonexistent. In the current
> case of importing functions from the environment (and we could have a looong
> philosophical conversation about whether this is a vulnerability in bash or
> in its callers, where the likely outcome is “not a vulnerability in bash but
> by far easiest to fix in bash”)

> Why would this be a philosophical discussion when there were clearly bugs in
> the parser allowing things it shouldn't even if you consider the use cases
> valid otherwise?

As I said in the snipped part, anyone able to submit arbitrary input to a shell 
can already cause it to do arbitrary things. The parser bugs do not give the 
attacker anything they don’t already have, so they are not security-relevant. 
So we are back to the philosophical discussion about where is the vulnerability 
in putting untrusted data into the environment. 
Mirek 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell


On 10/2/2014 11:13, Rahul Sundaram wrote:
Sure but the rationale isn't just security as I have explained 
earlier.  Do read the links and other mails fully.


I have read the emails fully.  Sure, I see where you said there were 
other reasons later in the discussion, but that's not what your original 
point was.  When I addressed that initial point, you ignored the basis 
of what I wrote and instead brought up a technicality regarding the 
scope of the switch.  When I pointed that out, you told me you ignored 
the point I was initially trying to make because it was irrelevant.  All 
I have been trying to do is simply make the point that it is relevant.  
Thank you for finally acknowledging the veracity of my argument.  I 
guess the third time really is the charm.


FYI, I am a contributor for pretty much the entire history of the 
project and we are merely discussing something.  Noone is expecting 
someone else to single handedly do anything.


I am fully aware of your status and I never said anything about someone 
having to do anything single-handed.  Do read what I have read fully and 
please don't put words in my mouth.


You know, you could've simply replied to my original take on your 
self-described opportunistic proposal with something like, "No, Tom, I'm 
not just making this proposal because of Shellshock.  I really think 
there are some merits to dash.  Here are a few..." or something like 
that.  Instead, I get a terse, cherry-picked, technical comment as to 
the scope of the switch followed by a bunch of rhetorical slight of hand 
as you change the focus.  Let's stay on target from now on, OK?



Tom

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell


Am 02.10.2014 um 17:53 schrieb Rahul Sundaram:
> On Thu, Oct 2, 2014 at 11:38 AM, Miloslav Trmač  wrote:
> The expected security improvement is essentially nonexistent.  In the 
> current case of importing functions from
> the environment (and we could have a looong philosophical conversation 
> about whether this is a vulnerability in
> bash or in its callers, where the likely outcome is “not a vulnerability 
> in bash but by far easiest to fix in
> bash”)
> 
> Why would this be a philosophical discussion when there were clearly bugs in 
> the parser allowing things it
> shouldn't even if you consider the use cases valid otherwise?

because the conclusion that dash is not vulerable for
other things is invalid - that needs to be proven and
not derived from known and *fixed* bugs in bash

not that i am against using things with less footprint
for many reasons, just the conclusion is wrong



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell

2014-10-02 Thread Tomasz Torcz

On Thu, Oct 02, 2014 at 11:53:18AM -0400, Rahul Sundaram wrote:
> Hi
> 
> On Thu, Oct 2, 2014 at 11:38 AM, Miloslav Trmač  wrote:
> 
> >
> > OK, then; care to explicitly list the advantages you expect to see from
> > such a switch, and why they outweigh the disadvantages and the migration
> > costs?
> >
> 
> I don't have a predrawn conclusion that I am advocating strongly for here
> but I am convinced it is worth a discussion.   So far from the discussions
> I have seen the advantages as reduced size ( dash is significantly smaller
> than bash) and this can be a nice advantage for containers etc,  POSIX
> correctness (/bin/sh should be only used by shell scripts that don't rely
> on Bash specific features),  performance (Zdenek Kabelac posted some
> numbers)

  Also it will reduce differences between Linux distribution. And take us
closed to what majority (Ubuntu and Debian) does.

-- 
Tomasz Torcz  ,,If you try to upissue this patchset I shall be 
seeking
xmpp: zdzich...@chrome.pl   an IP-routable hand grenade.'' -- Andrew Morton 
(LKML)

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell

2014-10-02 Thread Haïkel

I don't see any real benefit to move to dash since we get rid of sysV
init, no security improvements, but a lot of breakages to fix (Debian
spent a lot of time to fix bashisms in their packages ...)
That doesn't mean that we shouldn't consider it -this is a sane to
periodically re-assess our defaults-, but I need to hear what security
team thinks about it.

dash has a smaller codebase but is much less used than bash (and
people will end up installing bash or another full-featured shell so
it voids the security benefits) so I suspect we're not improving
security.

-

I'm more worried that many core components of the distro like bash
lack manpower, and I would prefer that we spent more efforts in
identifying them and see what we could do to improve the situation.

@Base WG: would you consider auditing the components of the base OS ?
Are they properly maintained or organize a security audit of the most
critical components ?


H.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Idea: Ability to define dependencies between coprs (correctly)

On Thu, Oct 02, 2014 at 05:48:20PM +0200, Honza Horak wrote:
> On 10/02/2014 05:18 PM, Pierre-Yves Chibon wrote:
> >On Thu, Oct 02, 2014 at 05:00:40PM +0200, Honza Horak wrote:
> >>Problem:
> >>Currently, copr allows to add a link to an arbitrary repo URL that is
> >>available for installing dependencies during building in copr. Using this
> >>dependent repo link we are able to build packages in coprA with dependencies
> >>in another coprB.
> >>
> >>However, when enabling only coprA and installing some packages from this
> >>copr, we can miss some packages from coprB, because those packages are not
> >>available since coprB is not enabled.
> >>
> >>Solution:
> >>We should be able to define dependency between coprs correctly. When
> >>creating coprA, we would add one or more depended coprs ('userB/coprB')
> >>instead of repo link. Then all packages from these coprs would be available
> >>during build, correct buildroots would be used (no need to specify variables
> >>$releasever and in addition, we would be able to provide correct (all) RPMs
> >>also when *installing* coprs.
> >>
> >>There are basically two ways how to implement this on the users' side:
> >>1) Simpler, preferred by Mirek, copr maintainer (CC'd):
> >>'copr' plugin in dnf would include -r option, which would basically
> >>installed all related coprs. That means when running `dnf copr enable -r
> >>userA/coprA`, user would end with two coprs enabled: userA/coprA and
> >>userB/coprB.
> >>
> >>2) More complicated, preferred by me :) :
> >>copr A repository from example above would not only include RPMs build as
> >>part of this copr, but would include also packages from copr B. That means
> >>that when running `dnf copr enable userA/coprA`, user would not need to
> >>install userB/coprB repository and would have all packages available.
> >>
> >>Both ways struggle with refreshing data:
> >>* in 1) we might need to refresh coprs enabled (on the users' side)
> >>* in 2) we would need to re-create repodata in depended coprA if coprB gets
> >>changed (on the server's side).
> >
> >What about putting the definition of the coprA on the coprB, ie at:
> >https://copr.fedoraproject.org/coprs/pingou/subsurface/repo/fedora-19/pingou-subsurface-fedora-19.repo
> >include the definition of the repo this copr depends on (ok bad example for 
> >this
> >specific copr).
> >
> >This way, it's rather clear to the user that the packages are coming from two
> >distinct copr, there no need to change dnf and we don't mix up in one repo
> >packages potentially built by different people.
> >
> >That does imply that existing .repo file might have to be updated.
> 
> Yeah, I like that idea, that would remove some obstacles mentioned for
> solution 1) above. I'm not sure though if the depended coprs can be called
> the same as the original (we would have two similar repos enabled) or we
> would have to call them differently. Just quick test does not show any
> issues with more repos with the same name.

As long as they point to the same url, I don't think having multiple definition
of the same repo is a problem :)

Pierre
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell

Hi

On Thu, Oct 2, 2014 at 11:38 AM, Miloslav Trmač  wrote:

>
> OK, then; care to explicitly list the advantages you expect to see from
> such a switch, and why they outweigh the disadvantages and the migration
> costs?
>

I don't have a predrawn conclusion that I am advocating strongly for here
but I am convinced it is worth a discussion.   So far from the discussions
I have seen the advantages as reduced size ( dash is significantly smaller
than bash) and this can be a nice advantage for containers etc,  POSIX
correctness (/bin/sh should be only used by shell scripts that don't rely
on Bash specific features),  performance (Zdenek Kabelac posted some
numbers)

On the flip side, there is probably some shell scripts that needs to be
fixed to use /bin/bash explicitly as opposed to assuming /bin/sh will
always be a symlink to bash. I can help write guidelines, check scripts,
file bug reports etc but even if we do fix the scripts we include within
the distribution (likely minimal since Debian/Ubuntu has switched over
several years back), users might have to fix their scripts which we don't
control.  Any user ability to reconfigure the default system shell has some
added complexity at the packaging level.   Dash also might need a security
review from someone competent to do it (ie) not me.

The expected security improvement is essentially nonexistent.  In the
> current case of importing functions from the environment (and we could have
> a looong philosophical conversation about whether this is a vulnerability
> in bash or in its callers, where the likely outcome is “not a vulnerability
> in bash but by far easiest to fix in bash”)
>

Why would this be a philosophical discussion when there were clearly bugs
in the parser allowing things it shouldn't even if you consider the use
cases valid otherwise?

Rahul
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Idea: Ability to define dependencies between coprs (correctly)

2014-10-02 Thread Honza Horak

On 10/02/2014 05:18 PM, Pierre-Yves Chibon wrote:

On Thu, Oct 02, 2014 at 05:00:40PM +0200, Honza Horak wrote:

Problem:
Currently, copr allows to add a link to an arbitrary repo URL that is
available for installing dependencies during building in copr. Using this
dependent repo link we are able to build packages in coprA with dependencies
in another coprB.

However, when enabling only coprA and installing some packages from this
copr, we can miss some packages from coprB, because those packages are not
available since coprB is not enabled.

Solution:
We should be able to define dependency between coprs correctly. When
creating coprA, we would add one or more depended coprs ('userB/coprB')
instead of repo link. Then all packages from these coprs would be available
during build, correct buildroots would be used (no need to specify variables
$releasever and in addition, we would be able to provide correct (all) RPMs
also when *installing* coprs.

There are basically two ways how to implement this on the users' side:
1) Simpler, preferred by Mirek, copr maintainer (CC'd):
'copr' plugin in dnf would include -r option, which would basically
installed all related coprs. That means when running `dnf copr enable -r
userA/coprA`, user would end with two coprs enabled: userA/coprA and
userB/coprB.

2) More complicated, preferred by me :) :
copr A repository from example above would not only include RPMs build as
part of this copr, but would include also packages from copr B. That means
that when running `dnf copr enable userA/coprA`, user would not need to
install userB/coprB repository and would have all packages available.

Both ways struggle with refreshing data:
* in 1) we might need to refresh coprs enabled (on the users' side)
* in 2) we would need to re-create repodata in depended coprA if coprB gets
changed (on the server's side).

What about putting the definition of the coprA on the coprB, ie at:
https://copr.fedoraproject.org/coprs/pingou/subsurface/repo/fedora-19/pingou-subsurface-fedora-19.repo
include the definition of the repo this copr depends on (ok bad example for this
specific copr).

This way, it's rather clear to the user that the packages are coming from two
distinct copr, there no need to change dnf and we don't mix up in one repo
packages potentially built by different people.

That does imply that existing .repo file might have to be updated.

Yeah, I like that idea, that would remove some obstacles mentioned for
solution 1) above. I'm not sure though if the depended coprs can be
called the same as the original (we would have two similar repos
enabled) or we would have to call them differently. Just quick test does
not show any issues with more repos with the same name.

Honza
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal: Increasing application icon sizes to 64px


Am 02.10.2014 um 17:34 schrieb Rahul Sundaram:
> On Thu, Oct 2, 2014 at 11:01 AM, Reindl Harald wrote:
> 
> you misunderstood me
> 
> I don't think anyone misunderstood that you have trouble 
> disagreeing without also being insulting

my god i brought an cynical example what upstream may write
in the changelog and i doubt that you people are that
hypersensitive about every single word in real life too

> You are pushing off people who might otherwise be sympathetic 
> to your  perspective  by constantly engaging in a discussion
> the way you do it.  Please stop.
> 
> *that* would be the exact message i would write in the
> log a upstream maintainer if someone tells me my
> application which works just fine needs a update
> because it otherwise is not displayed
> 
> Good thing that noone has asked for that. Please read the link

if nobody asked for that then Richard better had just only
posted that link and not written it word by word so people
don't care at all for a grpical installer would have ignored it

"or apps that haven't had an upstream release in 5 years"
is part of the mail i responded to *word by word* - no idea
where that leaves space for interpretation independent how
often quotes are stripped to lose context

 Weitergeleitete Nachricht 
Betreff: Re: Proposal: Increasing application icon sizes to 64px
Datum: Thu, 2 Oct 2014 15:32:02 +0100
Von: Richard Hughes 
Antwort an: Development discussions related to Fedora 

An: Development discussions related to Fedora 

On 2 October 2014 15:17, Tim Lauridsen  wrote:
> I think that is a bad idea to exclude applications from a Software manager,
> because they don't live up to some visual quality guidelines.

There's actually a whole load of reasons why we'd blacklist
applications: 
https://github.com/hughsie/appstream-glib#guidelines-for-applications
for instance programs that identify themselves as "settings" or apps
that haven't had an upstream release in 5 years



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell

2014-10-02 Thread Miloslav Trmač

Hello, 

> On Thu, Oct 2, 2014 at 10:48 AM, Tom Rivers wrote:

> > On 10/2/2014 09:58, Rahul Sundaram wrote:
> 

> > > I didn't address it because it was not really relevant either. The
> > > impetus
> > > is
> > > merely the backstory.
> > 
> 

> > On the contrary, the rationale for your proposed change is very relevant.
> 

> Sure but the rationale isn't just security as I have explained earlier. Do
> read the links and other mails fully.

OK, then; care to explicitly list the advantages you expect to see from such a 
switch, and why they outweigh the disadvantages and the migration costs? 

AFAICS: 

The expected security improvement is essentially nonexistent. In the current 
case of importing functions from the environment (and we could have a looong 
philosophical conversation about whether this is a vulnerability in bash or in 
its callers, where the likely outcome is “not a vulnerability in bash but by 
far easiest to fix in bash”), I expect/hope that the environment variable 
channel has been audited to death. Outside of this case, the shell is, by its 
nature, a programming language interpreter, and it doesn’t do any kind of 
privilege escalation: if you feed it arbitrary input, you get to do arbitrary 
things, but no more than you could do without the shell. The shell really 
should be transparent/fairly irrelevant to security (which is also why so 
little attention has been paid to it).¹ 

And as for any measure of performance, by the very fact that the scripts are 
written in shell we already know that the scripts are not performance-critical, 
or at least have not been worth optimizing for performance. 

So, it seems to me, all we are left with is a bit of performance/space 
optimization just because we can, at the very real cost of breaking existing 
scripts, both within the distribution and on users’s systems. 
Mirek 

¹ The exceptions being attacks through other programs that do escalate 
privileges and call shell with untrusted data (as in shellshock), and attacks 
through the shared environment (in this case, mainly filesystem contents and 
various small/constrainted states like the PID space). 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal: Increasing application icon sizes to 64px

Hi

On Thu, Oct 2, 2014 at 11:01 AM, Reindl Harald  wrote:

> you misunderstood me
>

I don't think anyone misunderstood that you have trouble disagreeing
without also being insulting.   You are pushing off people who might
otherwise be sympathetic to your perspective by constantly engaging in a
discussion the way you do it.  Please stop.

>
> *that* would be the exact message i would write in the
> log a upstream maintainer if someone tells me my
> application which works just fine needs a update
> because it otherwise is not displayed
>

Good thing that noone has asked for that.  Please read the link

Rahul
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell



On Wed, Oct 01, 2014 at 10:39:04PM -0400, Rahul Sundaram wrote:
> Is it worth considering using Dash as the default (non-interactive) shell
> in Fedora?  Other distributions including Ubuntu and Debian (

Thanks for bringing up the discussion. Just as we shouldn't change things
for no reason, we shouldn't leave the unexamined just because it's how we've
always done them.


-- 
Matthew Miller

Fedora Project Leader
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Idea: Ability to define dependencies between coprs (correctly)

On Thu, Oct 02, 2014 at 05:00:40PM +0200, Honza Horak wrote:
> Problem:
> Currently, copr allows to add a link to an arbitrary repo URL that is
> available for installing dependencies during building in copr. Using this
> dependent repo link we are able to build packages in coprA with dependencies
> in another coprB.
> 
> However, when enabling only coprA and installing some packages from this
> copr, we can miss some packages from coprB, because those packages are not
> available since coprB is not enabled.
> 
> Solution:
> We should be able to define dependency between coprs correctly. When
> creating coprA, we would add one or more depended coprs ('userB/coprB')
> instead of repo link. Then all packages from these coprs would be available
> during build, correct buildroots would be used (no need to specify variables
> $releasever and in addition, we would be able to provide correct (all) RPMs
> also when *installing* coprs.
> 
> There are basically two ways how to implement this on the users' side:
> 1) Simpler, preferred by Mirek, copr maintainer (CC'd):
> 'copr' plugin in dnf would include -r option, which would basically
> installed all related coprs. That means when running `dnf copr enable -r
> userA/coprA`, user would end with two coprs enabled: userA/coprA and
> userB/coprB.
> 
> 2) More complicated, preferred by me :) :
> copr A repository from example above would not only include RPMs build as
> part of this copr, but would include also packages from copr B. That means
> that when running `dnf copr enable userA/coprA`, user would not need to
> install userB/coprB repository and would have all packages available.
> 
> Both ways struggle with refreshing data:
> * in 1) we might need to refresh coprs enabled (on the users' side)
> * in 2) we would need to re-create repodata in depended coprA if coprB gets
> changed (on the server's side).

What about putting the definition of the coprA on the coprB, ie at: 
https://copr.fedoraproject.org/coprs/pingou/subsurface/repo/fedora-19/pingou-subsurface-fedora-19.repo
include the definition of the repo this copr depends on (ok bad example for this
specific copr).

This way, it's rather clear to the user that the packages are coming from two
distinct copr, there no need to change dnf and we don't mix up in one repo
packages potentially built by different people.

That does imply that existing .repo file might have to be updated.

Just a thought,
Pierre
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell

Hi

On Thu, Oct 2, 2014 at 10:48 AM, Tom Rivers  wrote:

> On 10/2/2014 09:58, Rahul Sundaram wrote:
>
>> I didn't address it because it was not really relevant either. The
>> impetus is merely the backstory.
>>
>
> On the contrary, the rationale for your proposed change is very relevant.
>

Sure but the rationale isn't just security as I have explained earlier.  Do
read the links and other mails fully.

>  There's an old saying:  No job is too big for the person that doesn't
have to do it.

FYI, I am a contributor for pretty much the entire history of the project
and we are merely discussing something.  Noone is expecting someone else to
single handedly do anything.

Rahul
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal: Increasing application icon sizes to 64px

2014-10-02 Thread Richard Hughes

On 2 October 2014 15:47, Reindl Harald  wrote:
> to make some distribution clown happy

If you read the link, if you ship an AppData file the 5 year rule
doesn't kick in. That's something useful that the packager *can* do to
the otherwise perfect desktop application.

Richard
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Bug 1139043] Review Request: perl-Array-Unique - Tie-able array that allows only unique values

2014-10-02 Thread bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=1139043



--- Comment #8 from Fedora Update System  ---
perl-Array-Unique-0.08-2.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/perl-Array-Unique-0.08-2.fc19

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=4KIHvjbl0h&a=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Idea: Ability to define dependencies between coprs (correctly)

2014-10-02 Thread Honza Horak


Hi all,

I have a proposal that would change how dependencies are defined in copr:

Problem:
Currently, copr allows to add a link to an arbitrary repo URL that is 
available for installing dependencies during building in copr. Using 
this dependent repo link we are able to build packages in coprA with 
dependencies in another coprB.


However, when enabling only coprA and installing some packages from this 
copr, we can miss some packages from coprB, because those packages are 
not available since coprB is not enabled.


Solution:
We should be able to define dependency between coprs correctly. When 
creating coprA, we would add one or more depended coprs ('userB/coprB') 
instead of repo link. Then all packages from these coprs would be 
available during build, correct buildroots would be used (no need to 
specify variables $releasever and in addition, we would be able to 
provide correct (all) RPMs also when *installing* coprs.


There are basically two ways how to implement this on the users' side:
1) Simpler, preferred by Mirek, copr maintainer (CC'd):
'copr' plugin in dnf would include -r option, which would basically 
installed all related coprs. That means when running `dnf copr enable -r 
userA/coprA`, user would end with two coprs enabled: userA/coprA and 
userB/coprB.


2) More complicated, preferred by me :) :
copr A repository from example above would not only include RPMs build 
as part of this copr, but would include also packages from copr B. That 
means that when running `dnf copr enable userA/coprA`, user would not 
need to install userB/coprB repository and would have all packages 
available.


Both ways struggle with refreshing data:
* in 1) we might need to refresh coprs enabled (on the users' side)
* in 2) we would need to re-create repodata in depended coprA if coprB 
gets changed (on the server's side).


Let's discuss this a bit, I'm eager to hear your opinions.

Cheers,
Honza
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal: Increasing application icon sizes to 64px


Am 02.10.2014 um 16:50 schrieb Pierre-Yves Chibon:
> On Thu, Oct 02, 2014 at 04:47:08PM +0200, Reindl Harald wrote:
>> Am 02.10.2014 um 16:32 schrieb Richard Hughes:
>>> On 2 October 2014 15:17, Tim Lauridsen  wrote:
 I think that is a bad idea to exclude applications from a Software manager,
 because they don't live up to some visual quality guidelines.
>>>
>>> There's actually a whole load of reasons why we'd blacklist
>>> applications: 
>>> https://github.com/hughsie/appstream-glib#guidelines-for-applications
>>> for instance programs that identify themselves as "settings" or apps
>>> that haven't had an upstream release in 5 years
>>
>> don't get me wrong but "haven't had an upstream release in 5 years"
>> is a silly reasoning - if an application works and has the feature
>> set it was intended to provide upstream needs to open the changelog
>> type there "to make some distribution clown happy", raise the version
>> number and the maintainer in the distribution too has useless work?
> 
> You may disagree and say so, but calling anyone a clown is not going to make
> your argument stronger, quite the contrary in fact.
> Please do not resolve to personal attack on this list

you misunderstood me

*that* would be the exact message i would write in the
log a upstream maintainer if someone tells me my
application which works just fine needs a update
because it otherwise is not displayed



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal: Increasing application icon sizes to 64px

On Thu, Oct 02, 2014 at 04:47:08PM +0200, Reindl Harald wrote:
> 
> Am 02.10.2014 um 16:32 schrieb Richard Hughes:
> > On 2 October 2014 15:17, Tim Lauridsen  wrote:
> >> I think that is a bad idea to exclude applications from a Software manager,
> >> because they don't live up to some visual quality guidelines.
> > 
> > There's actually a whole load of reasons why we'd blacklist
> > applications: 
> > https://github.com/hughsie/appstream-glib#guidelines-for-applications
> > for instance programs that identify themselves as "settings" or apps
> > that haven't had an upstream release in 5 years
> 
> don't get me wrong but "haven't had an upstream release in 5 years"
> is a silly reasoning - if an application works and has the feature
> set it was intended to provide upstream needs to open the changelog
> type there "to make some distribution clown happy", raise the version
> number and the maintainer in the distribution too has useless work?

You may disagree and say so, but calling anyone a clown is not going to make
your argument stronger, quite the contrary in fact.
Please do not resolve to personal attack on this list.

Pierre


pgpiMz5GnpMuF.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell


On 10/2/2014 09:58, Rahul Sundaram wrote:
I didn't address it because it was not really relevant either. The 
impetus is merely the backstory.


On the contrary, the rationale for your proposed change is very 
relevant.  The reasons for undertaking a project of this magnitude 
should be substantial because there is a substantial amount of work and 
research that must be done to ensure it is a good replacement and is 
implemented properly.  Not only that, but it could potentially impact a 
lot of people in ways that have yet to be thoroughly explored.  Prudence 
dictates an approach that isn't merely opportunistic as your original 
statements suggested.


There's an old saying:  No job is too big for the person that doesn't 
have to do it.  Asking others to undertake a project of this magnitude 
because some people were spooked by Shellshock is hardly a good reason.



Tom

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal: Increasing application icon sizes to 64px

Am 02.10.2014 um 16:32 schrieb Richard Hughes:
> On 2 October 2014 15:17, Tim Lauridsen  wrote:
>> I think that is a bad idea to exclude applications from a Software manager,
>> because they don't live up to some visual quality guidelines.
> 
> There's actually a whole load of reasons why we'd blacklist
> applications: 
> https://github.com/hughsie/appstream-glib#guidelines-for-applications
> for instance programs that identify themselves as "settings" or apps
> that haven't had an upstream release in 5 years

don't get me wrong but "haven't had an upstream release in 5 years"
is a silly reasoning - if an application works and has the feature
set it was intended to provide upstream needs to open the changelog
type there "to make some distribution clown happy", raise the version
number and the maintainer in the distribution too has useless work?

signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell

2014-10-02 Thread Florian Weimer


On 10/02/2014 03:07 PM, Chris Adams wrote:

Once upon a time, Richard W.M. Jones  said:

Changing the default /bin/sh is going to break the world.


[citation needed]


Just look for brace expansion in spec files.  It's use is *extremely* 
common.  And many of the failures are silent, e.g. arguments to “rm -f”.


We could patch rpmbuild to run them using bash instead, but this example 
makes it very doubtful to me that Ubuntu and Debian have already done 
all the hard work for us.


--
Florian Weimer / Red Hat Product Security
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

File Array-Unique-0.08.tar.gz uploaded to lookaside cache by dfateyev

2014-10-02 Thread Denis Fateyev

A file has been added to the lookaside cache for perl-Array-Unique:

e3fc4333a97c360348b8c7d0b6b94e83  Array-Unique-0.08.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Proposal: Increasing application icon sizes to 64px

2014-10-02 Thread Richard Hughes

On 2 October 2014 15:17, Tim Lauridsen  wrote:
> I think that is a bad idea to exclude applications from a Software manager,
> because they don't live up to some visual quality guidelines.

There's actually a whole load of reasons why we'd blacklist
applications: 
https://github.com/hughsie/appstream-glib#guidelines-for-applications
for instance programs that identify themselves as "settings" or apps
that haven't had an upstream release in 5 years.

Richard.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell

On Thu, Oct 02, 2014 at 03:21:33PM +0200, Lennart Poettering wrote:
> I am more concerned about code written by admins and users. I kinda
> hope that we don't ship too massive shell programs in Fedora, (well,
> except of course autoconf scripts...), but I am pretty sure that shell
> is one of the most common languages used by admins to do things, and
> that's where we should be really careful to not break things.

+1. Or a larger number than one. I know _for sure_ that there's a lot of
sysadmin scripts out there on RHEL, CentOS, and Fedora that start with
#!/bin/sh and then are full of bashisms. This is probably terrible, but it's
been that way and worked fine for since before Fedora existed, so here we
are.

Like all such change, that doesn't mean we _can't_ do it, but it means we're
asking users and admins to pay a price, and we should always make sure that
they're getting their metaphorical money's worth -- and that we do
everything we can to reduce the pain.

-- 
Matthew Miller

Fedora Project Leader
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal: Increasing application icon sizes to 64px

2014-10-02 Thread Tim Lauridsen

On Thu, Oct 2, 2014 at 11:17 AM, Richard Hughes  wrote:

> Designing an application for the lowest common denominator does not
> give you a high-quality cohesive application that's easy to use and
> nice on the eye. It gives you a miss-mash of ugly noise that's hard to
> use. I think it's fine that we are essentially saying "you have to do
> X, Y, Z to be showcased on the workstation". I've essentially slipped
> into the role of the person making the decisions about the software
> installer on the workstation product, and also upstream maintainer of
> most of this stuff. If anybody wants to refer any of my decisions up
> to the workstation working group, I'd be happy to talk to them, but
> I've a feeling they would be *less* forgiving than I'm currently
> being.
>

I think that is a bad idea to exclude applications from a Software manager,
because they don't live up to some visual quality guidelines.
It don't benfit the endusers, if the software manager only shows 50% of the
gui applications in the Fedora repositories.
What about not showing the icons if they dont have the need size, just show
a default icon based on the application category
they you have both the good look and a lot of applications.

Tim
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell

Hi

On Thu, Oct 2, 2014 at 9:56 AM, Miroslav Suchý  wrote:

> On 10/02/2014 04:39 AM, Rahul Sundaram wrote:
>
>> Is it worth considering using Dash as the default (non-interactive) shell
>> in Fedora?
>>
>
> Why starting with changing target of /bin/sh?
>
> Can we start with smaller step?
> Like put in Packing Guidelines, that authors and maintainers of
> non-interactive shell scripts should use
>   #!/usr/bin/dash
>

I don't think we need all scripts to do this.  Using sh when you are not
relying on any bash specific features is just fine.   Arch Linux wiki
suggests:

$checkbashisms -f -p $(grep -rlE '^#! ?/bin/(env )?sh' /usr/bin)

checkbashisms is part of devscripts-minimal in Fedora.

Rahul
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell

Once upon a time, Miroslav Suchý  said:
> Like put in Packing Guidelines, that authors and maintainers of 
> non-interactive shell scripts should use
>   #!/usr/bin/dash
> rather then
>   #!/bin/sh  or
>   #!/usr/bin/bash

No, /bin/sh is the standard-defined definitive place for the
POSIX-compliant scripting shell on Unix-like systems.

-- 
Chris Adams 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell

Hi

On Thu, Oct 2, 2014 at 9:49 AM, Tom Rivers  wrote:

> While I appreciate your technical correction on the scope of this proposed
> switch, you conveniently failed to address the core argument I made which
> is by far the larger issue:  the impetus...
>

I didn't address it because it was not really relevant either. The impetus
is merely the backstory.

Rahul
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell

2014-10-02 Thread Miroslav Suchý


On 10/02/2014 04:39 AM, Rahul Sundaram wrote:

Is it worth considering using Dash as the default (non-interactive) shell in 
Fedora?


Why starting with changing target of /bin/sh?

Can we start with smaller step?
Like put in Packing Guidelines, that authors and maintainers of non-interactive 
shell scripts should use
  #!/usr/bin/dash
rather then
  #!/bin/sh  or
  #!/usr/bin/bash

This change will hurt nobody. And enforce nothing.
And you can slowly start persuading maintainers to change that line. Package by 
package. Evolution rather than revolution.

BTW on my workstation:
$ grep '#!' *|grep /bin/sh|wc -l
535
$ grep '#!' *|grep /bin/bash |wc -l
87
$ grep '#!' *|grep /bin/dash |wc -l
0

--
Miroslav Suchy, RHCE, RHCDS
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell

Hi

On Thu, Oct 2, 2014 at 9:42 AM, Josh Boyer wrote:

> But the prompt for doing so is a security incident that has already
> been fixed.  If this was really a worthwhile endeavour, why hasn't it
> come up before?
>

Our needs continue to evolve.  We didn't consider size as much before but
there is a renewed focus in keeping the core small in part due to products
like Fedora Cloud.
The security issues brought up some related discussions elsewhere although
that isn't the key focus.  The size of dash is obviously much smaller. The
performance has been shown to be better.  It is already adopted by
Debian/Ubuntu for many years and I thought it might be worth considering
now regardless of the past.

Rahul
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell


On 10/2/2014 09:27, Rahul Sundaram wrote:
That is a mischaracterization. Bash will remain the interactive 
shell.  This discussion is limited  to switching the system shell 
(/bin/sh) from Bash to potentially Dash.


While I appreciate your technical correction on the scope of this 
proposed switch, you conveniently failed to address the core argument I 
made which is by far the larger issue:  the impetus for this switch is a 
knee-jerk overreaction to something that has already been patched.  As I 
stated previously, if this same logic were followed for every piece of 
software for which a vulnerability was discovered then a lot of software 
should be dumped as well.


There needs to be a better reason to switch to another piece of software 
other than, "Oh my God!  We found a bug!"



Tom
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell

2014-10-02 Thread Josh Boyer

On Thu, Oct 2, 2014 at 9:27 AM, Rahul Sundaram  wrote:
> Hi
>
> On Thu, Oct 2, 2014 at 9:18 AM, Tom Rivers wrote:
>>
>> So there's a vulnerability found in bash, it gets patched almost
>> immediately, and all of a sudden there's a push to abandon it altogether?
>
>
> That is a mischaracterization.  Bash will remain the interactive shell.
> This discussion is limited  to switching the system shell (/bin/sh) from
> Bash to potentially Dash.

But the prompt for doing so is a security incident that has already
been fixed.  If this was really a worthwhile endeavour, why hasn't it
come up before?  This is, at its core, a knee-jerk reaction with
little actual data to support a switch.

I would have rather seen this come up as a proposal with data showing
dash is faster or more secure or more compatible, etc.  Until
something like that shows up, I think we're just going to wind up with
a long thread that doesn't actually accomplish anything.

josh
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell

On Thu, Oct 02, 2014 at 08:05:09AM -0500, Chris Adams wrote:
> Once upon a time, Lennart Poettering  said:
> > If you change /bin/sh to dash, then you'll have to map two shell
> > binaries into memory (since the login shell is going to stay on bash),
> > hence the resource usage grows.
> 
> systemd (as PID 1, not counting additional required processes) takes
> over 10 times as much resident memory as dash.  Do you really want to go
> down that path?
> 
> > You increase the number of packages
> > and minimal footprint of our OS images since we need to install one
> > more package.
> 
> A true minimal-footprint install would not require bash, so this would
> reduce the size (dash installed size: 155K, bash installed size: 3.6M).
> 
> > You create a *lot* of porting work for all those
> > scripts. You *break* all scripts that currently reference /bin/sh in
> > the shebang-line but use bashisms.
> 
> Those scripts are already broken, and mostly already fixed because of
> Debian/Ubuntu (and *BSD, etc.).  The remaining scripts are largely going
> to be Fedora-specific, and that's not nearly as big of pile of code as
> you imply.
> 
> It is also funny to hear the systemd author talk about not breaking
> things and creating lots of work.

Could we please remain on the technical level and avoid personal attacks?

Thanks,
Pierre
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: How to handle upgrades to Fedora 21

2014-10-02 Thread Stephen Gallagher

On Thu, 2014-10-02 at 15:33 +0200, Miroslav Suchý wrote:
> On 09/24/2014 06:16 PM, Stephen Gallagher wrote:
> >   * Upgrades from Fedora 20 remain non-productized. They pick up
> > fedora-release-standard and upgrade only their existing packages.
> 
> Can you please explain to me, what is the difference between non-productized 
> Fedora and productized Fedora?
> 
> Do I understand it correctly that non-productized Fedora have 
> fedora-release-standard package, while productized one 
> have fedora-release-{cloud,workstation,server} package? Or is there some 
> other difference?

The presence of those packages makes other things possible (like adding
strict dependencies to the release packages to ensure a minimal platform
is available). Other things that it does is allow us to have yum
dependencies select an appropriate configuration sub-package for certain
projects that have different defaults between Products (the most obvious
example today being the firewalld package; it has a vastly different
default configuration depending on the Product).

signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: How to handle upgrades to Fedora 21

2014-10-02 Thread Miroslav Suchý


On 09/24/2014 06:16 PM, Stephen Gallagher wrote:

  * Upgrades from Fedora 20 remain non-productized. They pick up
fedora-release-standard and upgrade only their existing packages.


Can you please explain to me, what is the difference between non-productized 
Fedora and productized Fedora?

Do I understand it correctly that non-productized Fedora have fedora-release-standard package, while productized one 
have fedora-release-{cloud,workstation,server} package? Or is there some other difference?



--
Miroslav Suchy, RHCE, RHCDS
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell

Hi

On Thu, Oct 2, 2014 at 9:18 AM, Tom Rivers wrote:

> So there's a vulnerability found in bash, it gets patched almost
> immediately, and all of a sudden there's a push to abandon it altogether?
>

That is a mischaracterization.  Bash will remain the interactive shell.
This discussion is limited  to switching the system shell (/bin/sh) from
Bash to potentially Dash.

Rahul
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell

2014-10-02 Thread Lennart Poettering

On Thu, 02.10.14 14:12, Daniel P. Berrange (berra...@redhat.com) wrote:

> On Thu, Oct 02, 2014 at 08:07:14AM -0500, Chris Adams wrote:
> > Once upon a time, Richard W.M. Jones  said:
> > > Changing the default /bin/sh is going to break the world.
> > 
> > [citation needed]
> > 
> > Anything that depends on bash as /bin/sh is already getting Fedora
> > specific.  Debian/Ubuntu don't use bash as /bin/sh for years, and none
> > of the other major Unix-like systems (e.g. *BSD, Solaris, etc.) have
> > ever used bash as /bin/sh.
> > 
> > To say "it is a lot of work" or "is going to break the world", the
> > requirement for proof is on you.
> 
> Yep, I'm pretty sceptical that it would be alot of work because the
> vast majority of programs have long ago dealt with the pain in order
> to run on Debian correctly.  The only areas I'd see it being a problem
> is in Fedora/RHEL specific code. Stuff like initscripts (thankfully
> almost all killed due to systemd) and ifcfg-XXX network scripts (still
> around but mostly irrelevant if you are willing use NetworkManager).

I am more concerned about code written by admins and users. I kinda
hope that we don't ship too massive shell programs in Fedora, (well,
except of course autoconf scripts...), but I am pretty sure that shell
is one of the most common languages used by admins to do things, and
that's where we should be really careful to not break things.

Lennart

-- 
Lennart Poettering, Red Hat
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Wallpapers in portrait orientation

2014-10-02 Thread Miroslav Suchý


On 09/29/2014 09:57 PM, Bastien Nocera wrote:

Given that to generate them we would just crop the existing wallpapers, I'm not 
sure what the point is.


The point is to ask photographers to take some photos in portrait orientation.

--
Miroslav Suchy, RHCE, RHCDS
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell


On 10/1/2014 22:39, Rahul Sundaram wrote:
Since the recent Shellshock aka Bashdoor vulnerability, there have 
been some discussions about more distributions switching over...




So there's a vulnerability found in bash, it gets patched almost 
immediately, and all of a sudden there's a push to abandon it 
altogether?  If this is the proper thought process, then Heartbleed 
should've made everyone dump openSSL.  Carried to the extreme, most 
software should be completely abandoned then because none of it is 
completely bug free.  This sounds like mindless panic to me.


Also, let's not forget that SELinux is baked into Fedora.  Even if 
something does get access to the system, it is contained to a large 
degree.  This is something I seldom hear about when this particular bug 
is discussed in the media.



Tom
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell

2014-10-02 Thread Daniel P. Berrange

On Thu, Oct 02, 2014 at 08:07:14AM -0500, Chris Adams wrote:
> Once upon a time, Richard W.M. Jones  said:
> > Changing the default /bin/sh is going to break the world.
> 
> [citation needed]
> 
> Anything that depends on bash as /bin/sh is already getting Fedora
> specific.  Debian/Ubuntu don't use bash as /bin/sh for years, and none
> of the other major Unix-like systems (e.g. *BSD, Solaris, etc.) have
> ever used bash as /bin/sh.
> 
> To say "it is a lot of work" or "is going to break the world", the
> requirement for proof is on you.

Yep, I'm pretty sceptical that it would be alot of work because the
vast majority of programs have long ago dealt with the pain in order
to run on Debian correctly.  The only areas I'd see it being a problem
is in Fedora/RHEL specific code. Stuff like initscripts (thankfully
almost all killed due to systemd) and ifcfg-XXX network scripts (still
around but mostly irrelevant if you are willing use NetworkManager).

I'd be curious of the results if someone wants to take a stock Fedora 21
install and switch /bin/sh to point to dash and report if they can still
boot & login to GNOME.

I recently tried to change /bin/sh to point to /bin/false and the distro
was still surprisingly functional, against thanks to systemd removing
most use of shell from the boot process. The big problems with dhclient
spawning shell script, plymouth graphical boot, ssh key generation
and something I didn't investigate in X / GDM login.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell

Hi

On Thu, Oct 2, 2014 at 8:59 AM, Chris Adams  wrote:

>
> If that's the case, why do we have the /bin/sh symlink?  Just remove it
> and make the bash dependency explicit (so everything has to call
> /bin/bash).
>

I understand this is a rherotical argument but the symlink exists because
it is required by things like system()

Ex: execl("/bin/sh", "sh". "-c", command, (char *) 0);

Rahul
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell

Once upon a time, Richard W.M. Jones  said:
> Changing the default /bin/sh is going to break the world.

[citation needed]

Anything that depends on bash as /bin/sh is already getting Fedora
specific.  Debian/Ubuntu don't use bash as /bin/sh for years, and none
of the other major Unix-like systems (e.g. *BSD, Solaris, etc.) have
ever used bash as /bin/sh.

To say "it is a lot of work" or "is going to break the world", the
requirement for proof is on you.
-- 
Chris Adams 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell

Once upon a time, Lennart Poettering  said:
> If you change /bin/sh to dash, then you'll have to map two shell
> binaries into memory (since the login shell is going to stay on bash),
> hence the resource usage grows.

systemd (as PID 1, not counting additional required processes) takes
over 10 times as much resident memory as dash.  Do you really want to go
down that path?

> You increase the number of packages
> and minimal footprint of our OS images since we need to install one
> more package.

A true minimal-footprint install would not require bash, so this would
reduce the size (dash installed size: 155K, bash installed size: 3.6M).

> You create a *lot* of porting work for all those
> scripts. You *break* all scripts that currently reference /bin/sh in
> the shebang-line but use bashisms.

Those scripts are already broken, and mostly already fixed because of
Debian/Ubuntu (and *BSD, etc.).  The remaining scripts are largely going
to be Fedora-specific, and that's not nearly as big of pile of code as
you imply.

It is also funny to hear the systemd author talk about not breaking
things and creating lots of work.

-- 
Chris Adams 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell

Once upon a time, Lennart Poettering  said:
> The shell is API.

Yep, and that API is the POSIX shell language, an extended version of
the Bourne shell.  It is a Linux curiousity that came along to use bash
as /bin/sh.

> Currently, if people write shell (#!/bin/sh) scripts
> on Fedora, they can be sure that the same language is available on all
> Fedora installations. If you suddenly make /bin/sh something that
> might be different on all systems, you pretty much break API there.

Writing "#!/bin/sh" and expecting bash in inherently non-portable.
Anything that runs on more than one platform will have already found
that out.  Saying that Fedora can't use anything other than bash as
/bin/sh because of that is a very poor argument.

If that's the case, why do we have the /bin/sh symlink?  Just remove it
and make the bash dependency explicit (so everything has to call
/bin/bash).

> In general, I am pretty sure that except a couple of programming
> language or UNIX aficionades very few people can actually correctly
> separate bashisms from true bourneshellisms.

It isn't that hard.
-- 
Chris Adams 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Intent to update libinfinity to 0.6.1 (soname bump)

2014-10-02 Thread Rex Dieter

Rex Dieter wrote:

> Till Maas wrote:
> 
>> Hi,
>> 
>> On Sun, Sep 28, 2014 at 12:14:24PM +0200, Kalev Lember wrote:
>> 
>>> It's now retired in both F21 and master. Feel free to go ahead with the
>>> libinfinity builds.
>> 
>> thank you.
>> 
>> Rex, I prepared a new build for libqinfinity in the master branch, if
>> you point me to the SRPMs you would like to use for kte-collaborative
>> and liqinfinity,
> 
> I've libqinfinity handy,
> https://rdieter.fedorapeople.org/rpms/libqinfinity/
> 
> but looks like I may have left the kte-collaborative stuff on a different
> laptop.  (I'll try to dig it up later today or tomorrow).

I can't find my test kdte-collaborative build, but don't let that stop you, 
I'll just make a fresh snapshot when needed.

>> Would you agree to update F21 as well?
> 
> Good question, I'll see if can test this stuff more and ask others to
> share their opinions as well.

OK, I asked around and seems the consensus is that this is safe/ok for F21.

-- Rex


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Improving the offline updates user experience

2014-10-02 Thread Stephen Gallagher




On Fri, 2014-09-12 at 10:46 -0400, Stephen Gallagher wrote:
> == The Problem ==
> 
> It is very common for users to have systems with encrypted root
> partitions (or even just /var and /etc). This may be due to a personal
> concern for their data or a corporate policy mandating full-disk
> encryption. Disk encryption requires a password (or other more
> complicated credentials) be be presented just after the kernel is
> booted and before the drives can be mounted and their data read.
> 
> With the current implementation of the offline updates in Fedora, this
> leads to a very unpleasant user experience when updating. We offer two
> ways to perform offline updates in the default user environment of
> Fedora Workstation: "Install updates and reboot" or "Install updates
> and shut down".
> 
> With "Install updates and reboot", the behavior is as follows:
> 
> 1) The system shuts down and initiates an ACPI reboot.
> 2) The system presents the kernel boot menu and then starts the
> updater kernel.
> 3) The system presents the user with a password prompt for the disk
> encryption (possibly more than one, if the system is configured with
> different passwords for different partitions).
> 4) The offline updates occur.
> 5) The system shuts down and initiates an ACPI reboot.
> 6) The system presents the kernel boot menu and then starts the
> standard (possibly updated) kernel.
> 7) The system presents the user with a password prompt for the disk
> encryption (possibly more than one, if the system is configured with
> different passwords for different partitions).
> 8) The system completes booting.
> 
> During this experience, the user has been required to enter their disk
> encryption password *twice*. The same is true for the "Install and
> shut down" case, except that the two passwords are separated by some
> actual wallclock time.
> 
> == Proposed Improvements ==
> 
> We could significantly improve this situation by allowing the system
> to drop directly from the interactive system into the updater
> environment without doing a full reboot or relaunching the kernel.
> 
> Lennart, would it be possible to set up a special systemd target for
> performing updates that would essentially stop all processes except
> for systemd and then apply the updates?
> 
> In an ideal world, it would then also be possible after update is
> completed to restore operation to the standard boot targets of systemd
> so that the system comes back up without having to perform a total
> reboot. The exceptional case would of course be that in which either
> the kernel, libc or systemd[1] needed to be updated, in which case a
> reboot could be performed.
> 
> In this scenario, we can reduce the number of encrypted disk
> challenges to at most a single one, and that only if absolutely
> minimal plumbing packages saw an update.
> 
> I'd very much like to hear from the plumbers on this matter.
> 
> 
> [1] I'm told that this might not be necessary; that systemd can
> re-exec itself to pick up its own updates. That would reduce the scope
> presumably to "only the kernel" forcing reboots.


I'm bumping this thread to get comments from Lennart (CCed). There's a
lot of chatter in the conversation, but I'd very much like to hear an
answer to the specific questions I posed in this first email.


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell

2014-10-02 Thread Balint Szigeti

On Thu, 2014-10-02 at 12:07 +0200, Ralf Corsepius wrote:

> On 10/02/2014 11:25 AM, Balint Szigeti wrote:
> > On Thu, 2014-10-02 at 10:58 +0200, Ralf Corsepius wrote:
> >> On 10/02/2014 10:32 AM, Balint Szigeti wrote:
> >> > hello
> >> >
> >> > Don't we consider using zsh?
> >>
> >> I'd rather not. Thoughout its history, zsh has had lots of issues
> >> originating from limitations, bugs and incompatibilities.
> > hm... Interesting, I and my colleague use zsh and we don't have problem
> > with it.
> > Can you give some examples?
> Well, check autoconf's and automake's history of ca. the last 5 years. 
> There have been a quite some patches been added to work around zsh issues ;)
> 
> One case I am currently aware about is this:
> 
> # cat script
> SUBDIRS="a b  c"
> list=${SUBDIRS}; for subdir in $list; do
> echo $subdir
> done
> 
> # /bin/bash script
> a
> b
> c
> 
> Same result for dash and ksh, but for zsh:
> # /bin/zsh script
> a b  c
> 

Indeed. The zsh doesn't print the newline character after every entry.

> >> I don't know about the current situation, but e.g., the configure
> >> scripts I just posted the timings of for for bash and dash fail with zsh.
> > Which script do you mean?
> 
> I was referring to the files I used in 
> https://lists.fedoraproject.org/pipermail/devel/2014-October/202891.html
> 
> AFAICT so far, it fails because of behavioral difference between zsh and 
> bash/ksh/dash outlined above (the "script" example).
> 
> Ralf
> 
> 


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell


Am 02.10.2014 um 09:14 schrieb Tomasz Torcz:
> On Thu, Oct 02, 2014 at 08:33:23AM +0200, Lennart Poettering wrote:
>> since you have two packages to look after (Yes, by adding dash to the
>> default stack you just put the extra burden on Fedora to quickly
>> update two packages instead of just one in case of a security
>  
> Only if bash and dash share exactly the same security problems. 
> Which seems unlikely.

wrong - each can have each *own* security problems
and you are affected by the total summary of both
because they attacker can chose or try both






signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

rawhide report: 20141002 changes

2014-10-02 Thread Fedora Rawhide Report

Compose started at Thu Oct  2 05:15:04 UTC 2014
Broken deps for i386
--
[Agda]
ghc-Agda-2.3.2.2-5.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so
ghc-Agda-2.3.2.2-5.fc22.i686 requires libHShaskeline-0.7.0.3-ghc7.6.3.so
ghc-Agda-2.3.2.2-5.fc22.i686 requires 
ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5)
ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires 
libHSterminfo-0.3.2.5-ghc7.6.3.so
ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires 
libHShaskeline-0.7.0.3-ghc7.6.3.so
ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires 
ghc-devel(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5)
ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires 
ghc(terminfo-0.3.2.5-61e0dc43a1465e327dacd9ab37bbe1a3)
ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires 
ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5)
[PyQuante]
PyQuante-libint-1.6.4-11.fc22.1.i686 requires libint(x86-32) = 
0:1.1.6-2.fc21
[Sprog]
Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0)
[audtty]
audtty-0.1.12-9.fc20.i686 requires libaudclient.so.2
[authhub]
authhub-0.1.2-3.fc19.i686 requires libjson.so.0
[aws]
aws-devel-3.1.0-6.fc21.i686 requires libgrypt-devel
[blender]
1:blender-2.71-3.fc22.i686 requires libOpenCOLLADAStreamWriter.so.0.1
1:blender-2.71-3.fc22.i686 requires 
libOpenCOLLADASaxFrameworkLoader.so.0.1
1:blender-2.71-3.fc22.i686 requires libOpenCOLLADAFramework.so.0.1
1:blender-2.71-3.fc22.i686 requires libOpenCOLLADABaseUtils.so.0.1
1:blender-2.71-3.fc22.i686 requires libMathMLSolver.so.0.1
1:blender-2.71-3.fc22.i686 requires libGeneratedSaxParser.so.0.1
1:blenderplayer-2.71-3.fc22.i686 requires 
libOpenCOLLADAStreamWriter.so.0.1
1:blenderplayer-2.71-3.fc22.i686 requires 
libOpenCOLLADASaxFrameworkLoader.so.0.1
1:blenderplayer-2.71-3.fc22.i686 requires libOpenCOLLADAFramework.so.0.1
1:blenderplayer-2.71-3.fc22.i686 requires libOpenCOLLADABaseUtils.so.0.1
1:blenderplayer-2.71-3.fc22.i686 requires libMathMLSolver.so.0.1
1:blenderplayer-2.71-3.fc22.i686 requires libGeneratedSaxParser.so.0.1
[cab]
cab-0.1.9-12.fc22.i686 requires cabal-dev
[darcs]
darcs-2.8.4-5.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so
darcs-2.8.4-5.fc22.i686 requires libHShaskeline-0.7.0.3-ghc7.6.3.so
darcs-2.8.4-5.fc22.i686 requires 
ghc(terminfo-0.3.2.5-61e0dc43a1465e327dacd9ab37bbe1a3)
darcs-2.8.4-5.fc22.i686 requires 
ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5)
ghc-darcs-2.8.4-5.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so
ghc-darcs-2.8.4-5.fc22.i686 requires libHShaskeline-0.7.0.3-ghc7.6.3.so
ghc-darcs-2.8.4-5.fc22.i686 requires 
ghc(terminfo-0.3.2.5-61e0dc43a1465e327dacd9ab37bbe1a3)
ghc-darcs-2.8.4-5.fc22.i686 requires 
ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5)
ghc-darcs-devel-2.8.4-5.fc22.i686 requires 
ghc-devel(terminfo-0.3.2.5-61e0dc43a1465e327dacd9ab37bbe1a3)
ghc-darcs-devel-2.8.4-5.fc22.i686 requires 
ghc-devel(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5)
[debconf]
debconf-1.5.53-1.fc22.noarch requires perl(:MODULE_COMPAT_5.18.2)
[deltacloud-core]
deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires 
rubygem(cloudservers)
deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires 
rubygem(cloudfiles)
[django-recaptcha]
django-recaptcha-0.1-7.20091212svn6.fc21.noarch requires python-django14
[dnssec-check]
dnssec-check-1.14.0.1-4.fc20.i686 requires libval-threads.so.14
dnssec-check-1.14.0.1-4.fc20.i686 requires libsres.so.14
[dragonegg]
dragonegg-3.4-0.3.rc0.fc21.i686 requires gcc = 0:4.8.2-14.fc21
[eclipse-rse]
eclipse-rse-3.6.0-2.fc22.noarch requires osgi(org.eclipse.rse.services) 
= 0:3.3.0
[edelib]
edelib-2.1-5.fc22.i686 requires libedelib.so
edelib-devel-2.1-5.fc22.i686 requires libedelib.so
[eucalyptus]
eucalyptus-common-java-3.3.0-0.5.20130408git32052445.fc20.i686 requires 
hibernate3-jbosscache >= 0:3.6.10-7
[fatrat]
1:fatrat-1.2.0-0.21.beta2.fc22.i686 requires libtorrent-rasterbar.so.7
[flush]
flush-0.9.12-10.fc22.i686 requires libtorrent-rasterbar.so.7
[ga]
ga-openmpi-5.3b-9.fc21.i686 requires libmpi_usempi.so.1
[gedit-valencia]
gedit-valencia-0.4.0-1.20131223git94442bf.fc21.i686 requires 
libvala-0.24.so.0
[ghc-hjsmin]
ghc-hjsmin-0.1.4.7-3.fc22.i686 requires 
libHSoptparse-applicative-0.9.0-ghc7.6.3.so
[gnome-python2-desktop]
gnome-python2-metacity-2.32.0-18.fc21.i686 requires 
libmetacity-private.so.0
[gofer]
ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) >= 0:0.16.0
[hledger]
ghc-hledger-0.19.3-5.fc22.i686 requires 
libHSterminfo-0.3.2.5-ghc7.6.3.so
ghc-hledger-0.19.3-5.fc22.i686 requires 
libHShaskeline-0.7.

Re: Dash as default shell

On 10/02/2014 11:25 AM, Balint Szigeti wrote:

On Thu, 2014-10-02 at 10:58 +0200, Ralf Corsepius wrote:

On 10/02/2014 10:32 AM, Balint Szigeti wrote:
> hello
>
> Don't we consider using zsh?

I'd rather not. Thoughout its history, zsh has had lots of issues
originating from limitations, bugs and incompatibilities.

hm... Interesting, I and my colleague use zsh and we don't have problem
with it.
Can you give some examples?
Well, check autoconf's and automake's history of ca. the last 5 years. 
There have been a quite some patches been added to work around zsh issues ;)

One case I am currently aware about is this:

# cat script
SUBDIRS="a b  c"
list=${SUBDIRS}; for subdir in $list; do
echo $subdir
done

# /bin/bash script
a
b
c

Same result for dash and ksh, but for zsh:
# /bin/zsh script
a b  c

I don't know about the current situation, but e.g., the configure
scripts I just posted the timings of for for bash and dash fail with zsh.

Which script do you mean?

I was referring to the files I used in 
https://lists.fedoraproject.org/pipermail/devel/2014-October/202891.html

AFAICT so far, it fails because of behavioral difference between zsh and 
bash/ksh/dash outlined above (the "script" example).

Ralf

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

F-21 Branched report: 20141002 changes

2014-10-02 Thread Fedora Branched Report

Compose started at Thu Oct  2 07:15:02 UTC 2014
Broken deps for armhfp
--
[PyQuante]
PyQuante-libint-1.6.4-11.fc21.1.armv7hl requires libint(armv7hl-32) = 
0:1.1.6-2.fc21
[audtty]
audtty-0.1.12-9.fc20.armv7hl requires libaudclient.so.2
[authhub]
authhub-0.1.2-3.fc19.armv7hl requires libjson.so.0
[avro]
avro-mapred-1.7.5-9.fc21.noarch requires hadoop-mapreduce
avro-mapred-1.7.5-9.fc21.noarch requires hadoop-client
[cduce]
cduce-0.5.5-9.fc21.armv7hl requires ocaml(Camlp4) = 
0:ebd368022fd2bc7b305a42902efa4c90
[check-mk]
check-mk-agent-1.2.4p5-1.fc21.armv7hl requires /usr/bin/ksh
check-mk-multisite-1.2.4p5-1.fc21.noarch requires /usr/bin/ksh
[cp2k]
cp2k-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21
cp2k-mpich-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 
0:1.1.6-2.fc21
cp2k-openmpi-2.5.1-8.fc21.armv7hl requires libmpi_usempi.so.1
cp2k-openmpi-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 
0:1.1.6-2.fc21
[deltacloud-core]
deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires 
rubygem(cloudservers)
deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires 
rubygem(cloudfiles)
[django-recaptcha]
django-recaptcha-0.1-7.20091212svn6.fc21.noarch requires python-django14
[docker-registry]
docker-registry-0.7.3-1.fc21.noarch requires docker-io
[dragonegg]
dragonegg-3.4-0.3.rc0.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21
[edelib]
edelib-2.1-5.fc21.armv7hl requires libedelib.so
edelib-devel-2.1-5.fc21.armv7hl requires libedelib.so
[elpa]
elpa-openmpi-2013.11-4.008.fc21.armv7hl requires libmpi_usempi.so.1
[eucalyptus]
eucalyptus-common-java-3.3.0-0.5.20130408git32052445.fc20.armv7hl 
requires hibernate3-jbosscache >= 0:3.6.10-7
[fatrat]
1:fatrat-1.2.0-0.21.beta2.fc21.armv7hl requires 
libtorrent-rasterbar.so.7
[flashrom]
flashrom-0.9.6.1-5.svn1705.fc20.armv7hl requires libftdi.so.1
[flush]
flush-0.9.12-10.fc21.armv7hl requires libtorrent-rasterbar.so.7
[freesteam]
freesteam-ascend-2.1-6.20140724svn753.fc21.armv7hl requires 
libascend.so.1
[gcc-python-plugin]
gcc-python2-debug-plugin-0.12-18.fc21.armv7hl requires gcc = 
0:4.8.2-14.fc21
gcc-python2-plugin-0.12-18.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21
gcc-python3-debug-plugin-0.12-18.fc21.armv7hl requires 
libpython3.3dm.so.1.0
gcc-python3-debug-plugin-0.12-18.fc21.armv7hl requires gcc = 
0:4.8.2-14.fc21
gcc-python3-plugin-0.12-18.fc21.armv7hl requires libpython3.3m.so.1.0
gcc-python3-plugin-0.12-18.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21
[gdb-heap]
gdb-heap-0.5-18.fc21.armv7hl requires glibc(armv7hl-32) = 0:2.19.90
[gedit-valencia]
gedit-valencia-0.4.0-1.20131223git94442bf.fc21.armv7hl requires 
libvala-0.24.so.0
[glite-px-proxyrenewal]
glite-px-proxyrenewal-1.3.35-4.fc21.armv7hl requires libmyproxy.so.5
glite-px-proxyrenewal-libs-1.3.35-4.fc21.armv7hl requires 
libmyproxy.so.5
[gnome-python2-desktop]
gnome-python2-metacity-2.32.0-18.fc21.armv7hl requires 
libmetacity-private.so.0
[gnome-shell-extension-pomodoro]
gnome-shell-extension-pomodoro-0.10.0-4.fc21.armv7hl requires 
libupower-glib.so.2
[gofer]
ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) >= 0:0.16.0
[js-of-ocaml]
js-of-ocaml-1.3.2-4.fc21.armv7hl requires ocaml(Camlp4) = 
0:ebd368022fd2bc7b305a42902efa4c90
[leiningen]
leiningen-1.7.1-7.fc20.noarch requires maven-ant-tasks
leiningen-1.7.1-7.fc20.noarch requires classworlds
[libghemical]
libghemical-2.99.1-24.fc20.armv7hl requires libf77blas.so.3
libghemical-2.99.1-24.fc20.armv7hl requires libatlas.so.3
[libopensync-plugin-irmc]
1:libopensync-plugin-irmc-0.22-7.fc20.armv7hl requires libopenobex.so.1
[ltsp]
ltsp-client-5.4.5-8.fc21.armv7hl requires fuse-unionfs
ltsp-server-5.4.5-8.fc21.armv7hl requires cdialog
[meshmagick]
meshmagick-0.6.0-20.svn2898.fc21.armv7hl requires libOgreMain.so.1.8.1
meshmagick-libs-0.6.0-20.svn2898.fc21.armv7hl requires 
libOgreMain.so.1.8.1
[monodevelop-vala]
monodevelop-vala-2.8.8.1-6.fc21.armv7hl requires vala < 0:0.25.0
[netdisco]
netdisco-1.1-7.fc21.noarch requires perl(SNMP::Info::Layer2::Bay)
[ocaml-pa-do]
ocaml-pa-do-0.8.16-3.fc21.armv7hl requires ocaml(Camlp4) = 
0:ebd368022fd2bc7b305a42902efa4c90
[ocaml-pa-monad]
ocaml-pa-monad-6.0-15.fc21.armv7hl requires ocaml(Camlp4) = 
0:ebd368022fd2bc7b305a42902efa4c90
[ocaml-pgocaml]
ocaml-pgocaml-1.6-7.fc21.armv7hl requires ocaml(Camlp4) = 
0:ebd368022fd2bc7b305a42902efa4c90
[ocaml-pxp]
ocaml-pxp-1.2.4-3.fc21.armv7hl requires ocaml(Camlp4) = 
0:ebd368022fd2bc7b305a42902efa4c90
[openslides]
openslides-1.3.1-3.fc21.noarch requires python-django < 0:1.5
[open

Re: Dash as default shell


On 10/02/2014 11:04 AM, Zdenek Kabelac wrote:

Dne 2.10.2014 v 10:40 Ralf Corsepius napsal(a):

On 10/02/2014 09:47 AM, Zdenek Kabelac wrote:

Dne 2.10.2014 v 08:33 Lennart Poettering napsal(a):




It used to give significant boost for automake & libtool based software
- however at some point libtool started to use bashisms and so you
cannot just replace  /bin/sh -> dash - as build will fail.
(zsh doesn't seem to boost the speed)
My test cases do not involve libtool, just autoconf and automake 
generated files.



Also I said - upto 50% - which depends on complexity of configure files.
The complex case involves 47 recursive configure scripts and 329 
automake-generated Makefiles ;)



But even your personally measured 10% speed is in my eyes pretty
significant if you do builds all day and surely outweighs some RAM (and
IMHO even RAM will be actually still positive anyway on dash side if you
do parallel builds)
I do not share this view. IMO, reliability outweighs this speed up. 
Provided Fedora doesn't have any experience with dash, I am very 
reluctant on claims concerning dash.


Ralf

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell

2014-10-02 Thread Balint Szigeti

On Thu, 2014-10-02 at 10:58 +0200, Ralf Corsepius wrote:

> On 10/02/2014 10:32 AM, Balint Szigeti wrote:
> > hello
> >
> > Don't we consider using zsh?
> 
> I'd rather not. Thoughout its history, zsh has had lots of issues 
> originating from limitations, bugs and incompatibilities.

hm... Interesting, I and my colleague use zsh and we don't have problem
with it. 
Can you give some examples? 

> 
> I don't know about the current situation, but e.g., the configure 
> scripts I just posted the timings of for for bash and dash fail with zsh.

Which script do you mean?

> 
> Ralf
> 


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal: Increasing application icon sizes to 64px

2014-10-02 Thread Richard Hughes

On 1 October 2014 17:15, Tim Lauridsen  wrote:
> Is it only me, that is thinking, that all there rules to make things looks
> prettier in Gnome Software or  you package will get excluded if you dont
> live up to the rules

It's probably not just you.

> is a little hostile for packagers.

Actually, I'm trying to work upstream as much as possible. If you read
my blog, I've been doing frequent updates on just how many upstream
bugtrackers and maintainer emails I've sent. tl;dr: many hundreds.
Packagers are going to have to get involved if upstream is dead, but
that's the cost of being a package maintainer of obsolete or dead
software without letting it die by obsoleting it and removing it from
the distro.

> I understand that Richard, want his application to look so good as possible,
> but in the end it upstreams project there decides if they want to ship at
> buttugly icon in 16x16

Yes, it's totally up to them, but this should not preclude us making
rules for the workstation.

> Gnome software could workaround it by have some kind of cool frame to put
> around the icons  if they are to small to look good in the context of Gnome
> software.

Designing an application for the lowest common denominator does not
give you a high-quality cohesive application that's easy to use and
nice on the eye. It gives you a miss-mash of ugly noise that's hard to
use. I think it's fine that we are essentially saying "you have to do
X, Y, Z to be showcased on the workstation". I've essentially slipped
into the role of the person making the decisions about the software
installer on the workstation product, and also upstream maintainer of
most of this stuff. If anybody wants to refer any of my decisions up
to the workstation working group, I'd be happy to talk to them, but
I've a feeling they would be *less* forgiving than I'm currently
being.

Richard
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell

2014-10-02 Thread Zdenek Kabelac


Dne 2.10.2014 v 10:40 Ralf Corsepius napsal(a):

On 10/02/2014 09:47 AM, Zdenek Kabelac wrote:

Dne 2.10.2014 v 08:33 Lennart Poettering napsal(a):



On the other hand - usage of dash significantly speeds up  compilation of
autoconf projects - it's pretty interesting to see the compilation with
dash
is then maybe even 50% faster in non optimized builds (depends on how
many shells are forked during autoconf builds)


I don't know what you tested, but I don't see a substantial speed up on
running autoconf-generated configure scripts:

# time SHELL=/bin/bash CONFIG_SHELL=/bin/bash /bin/bash ../configure ...
...
real0m5.775s
user0m0.528s
sys0m0.217s

# time SHELL=/bin/dash CONFIG_SHELL=/bin/dash /bin/dash ../configure ...
...
real0m5.495s
user0m0.340s
sys0m0.194s


Another, more extensive test case:
* bash;
real1m43.115s
user0m34.708s
sys0m16.322s

* dash:
real1m33.283s
user0m30.834s
sys0m13.932s

In other words, I am observing a 5-10% speed up on running autoconf configure
scripts.


Unsure how does your 'bash' environment setup looks like - but on pretty 
simple lvm configure case - but my rawhide (on C2D 2.1GHz, SSD)


dash:

real0m2.819s
user0m0.770s
sys 0m2.098s

bash:

real0m3.600s
user0m1.211s
sys 0m2.695s


xf86-video-intel (intel drm driver)

dash:

real0m8.691s
user0m4.639s
sys 0m4.153s


bash:

real0m9.852s
user0m5.241s
sys 0m4.982s


It used to give significant boost for automake & libtool based software - 
however at some point libtool started to use bashisms and so you cannot just 
replace  /bin/sh -> dash - as build will fail.

(zsh doesn't seem to boost the speed)

Also I said - upto 50% - which depends on complexity of configure files.

But even your personally measured 10% speed is in my eyes pretty significant 
if you do builds all day and surely outweighs some RAM (and IMHO even RAM will 
be actually still positive anyway on dash side if you do parallel builds)


Zdenek



--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell


On 10/02/2014 10:32 AM, Balint Szigeti wrote:

hello

Don't we consider using zsh?


I'd rather not. Thoughout its history, zsh has had lots of issues 
originating from limitations, bugs and incompatibilities.


I don't know about the current situation, but e.g., the configure 
scripts I just posted the timings of for for bash and dash fail with zsh.


Ralf

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell

2014-10-02 Thread Timothée Ravier

On 2014-10-02 10:25, Rahul Sundaram wrote:
>> It doesn't even avoid Debian & Ubuntu having a security problem, since
>> they still need to fix bash.
> 
> Sure.  Unless they stop shipping bash, they got to fix security problems.
> That is no surprise.  The real question is whether it reduced the impact of
> the issue for their users.
> 
>> What makes you think the dash doesn't have vulnerabilities too?
> 
> Do note that I explicitly avoided making any such specific claims and
> instead proposed it as a discussion point for a good reason.Having said
> that, the general understanding appears to be that a minimal software with
> a smaller footprint has less potential issues.

It's easy to forget that there have been much more serious
vulnerabilities in dash than in bash as far as I can remember:
http://blog.cmpxchg8b.com/2013/08/security-debianisms.html

-- 
Timothée Ravier
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell


On 10/02/2014 09:47 AM, Zdenek Kabelac wrote:

Dne 2.10.2014 v 08:33 Lennart Poettering napsal(a):



On the other hand - usage of dash significantly speeds up  compilation of
autoconf projects - it's pretty interesting to see the compilation with
dash
is then maybe even 50% faster in non optimized builds (depends on how
many shells are forked during autoconf builds)


I don't know what you tested, but I don't see a substantial speed up on 
running autoconf-generated configure scripts:


# time SHELL=/bin/bash CONFIG_SHELL=/bin/bash /bin/bash ../configure ...
...
real0m5.775s
user0m0.528s
sys 0m0.217s

# time SHELL=/bin/dash CONFIG_SHELL=/bin/dash /bin/dash ../configure ...
...
real0m5.495s
user0m0.340s
sys 0m0.194s


Another, more extensive test case:
* bash;
real1m43.115s
user0m34.708s
sys 0m16.322s

* dash:
real1m33.283s
user0m30.834s
sys 0m13.932s

In other words, I am observing a 5-10% speed up on running autoconf 
configure scripts.


Ralf

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell

2014-10-02 Thread Balint Szigeti

hello

Don't we consider using zsh?

Balint

On Thu, 2014-10-02 at 10:04 +0200, Florian Weimer wrote:

> On 10/02/2014 09:14 AM, Tomasz Torcz wrote:
> 
> >/bin/sh isn't supposed to "stay in memory". It's for one-off scripts,
> > not for interactive use.
> 
> It will stay in memory around command invocations, and the executable 
> code and mapped data will remain in the page cache (hopefully).
> 
> Allegedly, dash has reduced memory requirements, so the net benefit 
> might still be positive, but it seems unlikely.  For small (cloud) 
> images, it might be interesting to get rid of bash altogether, but 
> considering how many scripts start with #!/bin/bash instead of 
> #!~/bin/sh, it's not likely to work.
> 
> If we are not satisfied with bash, I think we are all better off with 
> improving bash.
> 
> -- 
> Florian Weimer / Red Hat Product Security


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell

Hi

On Thu, Oct 2, 2014 at 4:04 AM, Richard W.M. Jones  wrote:

> On Wed, Oct 01, 2014 at 10:39:04PM -0400, Rahul Sundaram wrote:
> For Ubuntu the stated reason to follow Debian was pretty bogus[1] --
>

Ubuntu didn't follow Debian here.  It was the other way around.

>
> It doesn't even avoid Debian & Ubuntu having a security problem, since
> they still need to fix bash.

Sure.  Unless they stop shipping bash, they got to fix security problems.
That is no surprise.  The real question is whether it reduced the impact of
the issue for their users.

> What makes you think the dash doesn't have vulnerabilities too?
>

Do note that I explicitly avoided making any such specific claims and
instead proposed it as a discussion point for a good reason.Having said
that, the general understanding appears to be that a minimal software with
a smaller footprint has less potential issues.

Rahul
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell

2014-10-02 Thread Florian Weimer


On 10/02/2014 09:14 AM, Tomasz Torcz wrote:


   /bin/sh isn't supposed to "stay in memory". It's for one-off scripts,
not for interactive use.


It will stay in memory around command invocations, and the executable 
code and mapped data will remain in the page cache (hopefully).


Allegedly, dash has reduced memory requirements, so the net benefit 
might still be positive, but it seems unlikely.  For small (cloud) 
images, it might be interesting to get rid of bash altogether, but 
considering how many scripts start with #!/bin/bash instead of 
#!~/bin/sh, it's not likely to work.


If we are not satisfied with bash, I think we are all better off with 
improving bash.


--
Florian Weimer / Red Hat Product Security
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell

2014-10-02 Thread Richard W.M. Jones

On Wed, Oct 01, 2014 at 10:39:04PM -0400, Rahul Sundaram wrote:
> Hi
> 
> Is it worth considering using Dash as the default (non-interactive) shell
> in Fedora?  Other distributions including Ubuntu and Debian (
> https://lwn.net/Articles/343924/) have been using dash as the default shell
> and Android uses mksh.  While this appears to have been done primary to
> increase bootup efficiency (which is not relevant with systemd), it might
> help with security

[Quoting an email I sent internally in Red Hat]

Changing the default /bin/sh is going to break the world.

I've never understood the reasoning for Debian using a useless shell
for /bin/sh instead of the more pleasant, full-featured bash.

For Ubuntu the stated reason to follow Debian was pretty bogus[1] --
using dash instead of bash was thought to save some time in SysV init
scripts, and by changing the default shell they wouldn't need them to
change all the scripts from #!/bin/sh -> #!/bin/dash because using a
recursive search and replace is far too arduous.  The actual saving
was never AFAIK quantified, but I doubt it was measurable.  In any
case this is irrelevant for systemd.

It doesn't even avoid Debian & Ubuntu having a security problem, since
they still need to fix bash.

[1] https://wiki.ubuntu.com/DashAsBinSh

> Since the recent Shellshock aka Bashdoor vulnerability, there have been
> some discussions about more distributions switching over (
> http://lwn.net/SubscriberLink/614218/019d9a52b0eaae3d/) and I was wondering
> whether it is worth considering for Fedora?  FWIW, both dash and mksh is
> already packaged in Fedora.

bash had a vulnerability - a bit stupid in hindsight, but no one
spotted it for 20-odd years.  And it's been fixed.

What makes you think the dash doesn't have vulnerabilities too?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell

2014-10-02 Thread Zdenek Kabelac


Dne 2.10.2014 v 08:33 Lennart Poettering napsal(a):

On Wed, 01.10.14 22:39, Rahul Sundaram (methe...@gmail.com) wrote:


Hi

Is it worth considering using Dash as the default (non-interactive) shell
in Fedora?  Other distributions including Ubuntu and Debian (
https://lwn.net/Articles/343924/) have been using dash as the default shell
and Android uses mksh.  While this appears to have been done primary to
increase bootup efficiency (which is not relevant with systemd), it might
help with security

Since the recent Shellshock aka Bashdoor vulnerability, there have been
some discussions about more distributions switching over (
http://lwn.net/SubscriberLink/614218/019d9a52b0eaae3d/) and I was wondering
whether it is worth considering for Fedora?  FWIW, both dash and mksh is
already packaged in Fedora.


This sounds really wrong to me.

If you change /bin/sh to dash, then you'll have to map two shell
binaries into memory (since the login shell is going to stay on bash),
hence the resource usage grows. You increase the number of packages



When I look in my memory footprint where NetworkManager grabs 20M of RAM
and does nearly nothing whole day - it's funny to even hear dash would 
consuming some significant memory resources.


I suggest to look at other places first if you really care about this.

On the other hand - usage of dash significantly speeds up  compilation of
autoconf projects - it's pretty interesting to see the compilation with dash
is then maybe even 50% faster in non optimized builds (depends on how many 
shells are forked during autoconf builds)


So you may have two shells in RAM - when dash is pretty minimalistic,
and you save tons CPU cycles and seconds on i.e. compile time (being 
environment friendly :)


So while I don't care which shell is default - the argument about memory is 
not worth to mentions


Zdenek

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell

2014-10-02 Thread Ian Malone

On 2 October 2014 07:33, Lennart Poettering  wrote:
> On Wed, 01.10.14 22:39, Rahul Sundaram (methe...@gmail.com) wrote:
>
>> Hi
>>
>> Is it worth considering using Dash as the default (non-interactive) shell
>> in Fedora?  Other distributions including Ubuntu and Debian (
>> https://lwn.net/Articles/343924/) have been using dash as the default shell
>> and Android uses mksh.  While this appears to have been done primary to
>> increase bootup efficiency (which is not relevant with systemd), it might
>> help with security
>>
>> Since the recent Shellshock aka Bashdoor vulnerability, there have been
>> some discussions about more distributions switching over (
>> http://lwn.net/SubscriberLink/614218/019d9a52b0eaae3d/) and I was wondering
>> whether it is worth considering for Fedora?  FWIW, both dash and mksh is
>> already packaged in Fedora.
>
> This sounds really wrong to me.
>
> If you change /bin/sh to dash, then you'll have to map two shell
> binaries into memory (since the login shell is going to stay on bash),
> hence the resource usage grows. You increase the number of packages
> and minimal footprint of our OS images since we need to install one
> more package.

Total download size: 91 k
Installed size: 163 k


> You also increase the attack surface, since there'll be
> two shells running. You have to maintain + security-fix more code,

Versus this the default shell may be more exposed, it plays a
particular role in the system. As does a login shell. To be honest
most people do not need bashisms in the login shell either

> since you have two packages to look after (Yes, by adding dash to the
> default stack you just put the extra burden on Fedora to quickly
> update two packages instead of just one in case of a security
> problem). You create a *lot* of porting work for all those
> scripts. You *break* all scripts that currently reference /bin/sh in
> the shebang-line but use bashisms. Also, many of the bashisms are

/bin/sh scripts usings bashisms are broken already, you merely expose
it. Much of this work will have been done in debian/ubuntu already. I
was under the impression the move was away from system scripts in any
case.

> actually pretty useful, hence you replace a more powerful language by
> a crappier one. You create an entirely new problem for our users, by

Well, less powerful is not 'crappier'. It may well be the lower
complexity of dash that contributed to bash being the first one to
show up a vulnerability.

> making them *think* whether they actually mean /bin/sh or
> /bin/bash. You confuse users by disallowing certain expressions in
> scripts that work fine if you type them on the interactive shell.

None of this is a problem. You also have to think whether you mean
/bin/sh or /usr/bin/python. Or .c or .cxx.

>
> So, in order to keep things simpler, faster, more secure, more
> maintainable, more compatible, let's please stick with one shell and
> one shell only, and let's stay with bash. Thank you.
>

I'm not a big dash partisan, whenever I write a shell script more
often than not it starts /bin/bash, but this at least needs some
consideration. Fedora has made quite a few radical changes in the
past, with mixed results. This is a not very radical change that's
been used for quite some time in other distros and doesn't actually
break POSIX for once.

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Base] F21 Alpha Docker base image release

2014-10-02 Thread Václav Pavlín



On 2.10.2014 00:03, Dennis Gilmore wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, 01 Oct 2014 09:56:32 +0200
Václav Pavlín  wrote:


Hi,

Dennis, could you please build Alpha base image with updated bash?
(And probably also prepare F20 and Rawhide images so that we can
really call the Fedora image official with all it's tags?

There is no looking back Alpha is done, Beta TC1 is out the door,
though the docker image is missing with kokji down I can not see why it
failed to compose. We can not go back.  Fedora 20 will never have
official docker images and we produce branched and rawhide images
nightly. so there is plenty of newer images available not sure what you
mean by "with all it's tags?"
I probably don't understand - why is it impossible to build F20 image? 
By "with all it's tags" I mean so that we can have fedora:20, fedora:21 
and fedora:rawhide in Docker Hub




We should probably also consider using Fedora Cloud SIG account on
github to push these image to Docker Automated builds - it would
probably look better then using Lokesh's account (no offence:) ).

hithub is not an acceptable medium to use for Fedora release
engineering. as I understand it docker do not care where it is hosted
so long as things are in git that they can pull from. so we will use
fedorahosted.
Right, I haven't realized we can use any git - fedorahosted is 
definitely the correct place in this case.



The *interim* workflow for uploading official Fedora image to Docker
Hub would be:

1. Download tar.gz and ks from Koji
2. Unpack
3. Compress layer.tar as xz

not acceptable. if we must use different compression we will adjust
koji to compress things differently. we do not do manipulation of the
deliverables, we take them as they come out.

The problem is that we have image with metadata

.
├── repositories
└── 20bb2f8f723c9244e8c7f5b09edbbadff5dfa38c2e4165d3cfdb19ba6a2d1a6e
├── json
├── *layer.tar*
└── VERSION

And what we need to provide to Docker Automated builds is only the file 
layer.tar





4. Upload Dockerfile, ks and *.tar.xz to Fedora Cloud SIG github
repository (same as

releng will upload to fedorahosted.


https://github.com/lsm5/docker-brew-fedora/tree/21) 5. Update
https://github.com/docker-library/official-images/blob/master/library/fedora

I agree with Matt we should ship what we have and follow up with
Docker on enablement of import for our images (containing metadata)
built in Koji.

I am all for shipping what we have. we need to work out how to actually
do it.


Does this make sense to you? If there will be no objections, could we
vote?

- -1 for your proposal as is.


Lokesh, would you like to continue to maintain the process of getting
Fedora Docker base images to the audience?

Thanks & regards,
Vašek


-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBAgAGBQJULHotAAoJEH7ltONmPFDRWI4P+wf14y47GL+yVeCvdVm9iqWl
uxIqZrKyxjtRn8s7aDFyGKBf92WinVtP8rZrpvtA3Kmb4prJ/0vT64JxxLhwR6rM
jg4s8FaqdM7JJtIHzkowWGTxU45pNo2mv1CJ3i6z4Wx3pXMRs4uaY1SZUxoObgS4
O7qbm7qWL6Moh/ybCJ0IFgqKxVq5vF9U/vJLA07otoGZuD75RZ5+OcStokgH7HmJ
zJSqSVFa8iuDAIPjvI4rK6PA9Dm/iMYPMYJ8Cl1XcU4xBOe1F18nOyWHZH4TxKvX
zYUEFP6oF9GVmzny0+0cY3XQ7q4JWK8i0GkTr1Q9uZyEGT9Li992dmud8IUKE6Y5
dte0bahC+LjQrGfG/YsAMfzOtggoIhANm/fjNxsPZyYV7n6dJ8fieM0x1ZJhNdBM
fIzeHFS/SaILmFGcEeD8ZFkXlp8kbHoYkP30u0mtDmovOXwqbbyhri7tgoZBKgUc
bjAKwFQ/IlPsfyzJaQnSzK5DVOfkb3oD2EdkM3uTd2qOR3alRiPxm5UYNdx5NEbE
SMo/dcYBPcs8ly+iLzyDY2dtkL9lGM/ZXARgrLYWGVWY5GiERLI9CeCiMaw9ukgY
WRoGjGZzVL/kBg4iz7BU69mbNniwcSXOtxklKWkAlVRzrWW/QPqmrJLLCf8RJUPg
/L8NZ1S02hNRjoi6TesD
=KnPu
-END PGP SIGNATURE-


--

Lead Infrastructure Engineer
Developer Experience
Brno, Czech Republic

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell

2014-10-02 Thread Tomasz Torcz

On Thu, Oct 02, 2014 at 08:33:23AM +0200, Lennart Poettering wrote:
> On Wed, 01.10.14 22:39, Rahul Sundaram (methe...@gmail.com) wrote:
> 
> > Hi
> > 
> > Is it worth considering using Dash as the default (non-interactive) shell
> > in Fedora?  Other distributions including Ubuntu and Debian (
> > https://lwn.net/Articles/343924/) have been using dash as the default shell
> > and Android uses mksh.  While this appears to have been done primary to
> > increase bootup efficiency (which is not relevant with systemd), it might
> > help with security
> > 
> > Since the recent Shellshock aka Bashdoor vulnerability, there have been
> > some discussions about more distributions switching over (
> > http://lwn.net/SubscriberLink/614218/019d9a52b0eaae3d/) and I was wondering
> > whether it is worth considering for Fedora?  FWIW, both dash and mksh is
> > already packaged in Fedora.
> 
> This sounds really wrong to me.
> 
> If you change /bin/sh to dash, then you'll have to map two shell
> binaries into memory (since the login shell is going to stay on bash),
> hence the resource usage grows. You increase the number of packages
> and minimal footprint of our OS images since we need to install one
> more package. You also increase the attack surface, since there'll be
> two shells running. You have to maintain + security-fix more code,

  /bin/sh isn't supposed to "stay in memory". It's for one-off scripts,
not for interactive use.

> since you have two packages to look after (Yes, by adding dash to the
> default stack you just put the extra burden on Fedora to quickly
> update two packages instead of just one in case of a security
 
  Only if bash and dash share exactly the same security problems. Which
seems unlikely.

> problem). You create a *lot* of porting work for all those

  Ubuntu/Debian did a lot of porting/cleanup work in the years after
switching away from bash. We can assume all this proting went upstream
and we can just ride on their work.

> scripts. You *break* all scripts that currently reference /bin/sh in
> the shebang-line but use bashisms. Also, many of the bashisms are
> actually pretty useful, hence you replace a more powerful language by
> a crappier one. You create an entirely new problem for our users, by
> making them *think* whether they actually mean /bin/sh or
> /bin/bash. You confuse users by disallowing certain expressions in
> scripts that work fine if you type them on the interactive shell.
> 
> So, in order to keep things simpler, faster, more secure, more
> maintainable, more compatible, let's please stick with one shell and
> one shell only, and let's stay with bash. Thank you.

  So we shouldn't diverge from dash as /bin/sh?  There are probably more
Debian+Ubuntu servers than Fedora servers, so majority of systems have dash.
"Staying" with bash would mean diverging from majority.

-- 
Tomasz Torcz  ,,If you try to upissue this patchset I shall be 
seeking
xmpp: zdzich...@chrome.pl   an IP-routable hand grenade.'' -- Andrew Morton 
(LKML)

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Dash as default shell