On Fri, Sep 26, 2014 at 9:50 PM, Doug Newgard wrote:
>> The problem is on many systems /bin/sh is linked to bash -- which is why
>> this bug is so widespread / severe. /bin/sh is "the single biggest
>> UNIX loophole", so let's make it a bit smaller by switching it to
>> something minimal, such as
On Fri, Sep 26, 2014 at 8:40 PM, Drake Wilson wrote:
> Aside: I'm not sure about the interpretation of checkbashisms re autotools
> scripts (in particular libtool) because they do an awful lot of weird code
> generation and shuffling to deal with multiple bogus shell implementations.
Yes, you'd e
On Fri, Sep 26, 2014 at 8:19 PM, Mailing Lists
wrote:
> On Fri, Sep 26, 2014, at 05:43 PM, Martti Kühne wrote:
>> Removing bashisms would not have any inpact in security but rather
>> enable us switching /bin/sh away from /usr/bin/bash. Which we in
>> general appear to agree on?
>>
>> cheers!
>> m
On Fri, Sep 26, 2014 at 8:13 PM, Martti Kühne wrote:
> On Fri, Sep 26, 2014 at 2:06 PM, Mailing Lists
> wrote:
>>
>> Even if we agree to shift /bin/sh to dash, I'm not sure that it'll make
>> that much of a difference. From what I've read, most of the problems
>> come from CGI scripts which invok
On Fri, Sep 26, 2014 at 6:06 PM, Mailing Lists
wrote:
>
> i just ran the "checkbashisms" script from the AUR on my /usr/bin using
> the command from the wiki:
>
> # checkbashisms -f -p $(grep -rlE '^#! ?/bin/(env )?sh' /usr/bin)
>
> which revealed 470 instances of putative bashisms in scripts usin
On Fri, Sep 26, 2014 at 4:20 PM, Martti Kühne wrote:
[...]
> Despite that I'm still not convinced as to why
> the issue in question is such a big deal, I must say it's unlikely
> we're better off with a less active, less used shell.
Put simply, bash has too much bloat. That includes obscure dark
On Fri, Sep 26, 2014 at 3:11 PM, Martti Kühne wrote:
> Arch cannot realistically switch away from bash as long as both its
> package management depends on it for both package creation and package
> management tasks.
But we can switch away from using bash as /bin/sh.
On Fri, Sep 26, 2014 at 6:54 AM, Ralf Mardorf
wrote:
> On Fri, 2014-09-26 at 06:24 +0800, lolilolicon wrote:
>> Anything that has the #!/bin/sh line should be written in pure sh.
>> If you want bash, ask for bash.
>
> I absolutely agree with your statement and that is why I d
On Fri, Sep 26, 2014 at 6:06 AM, Leonid Isaev wrote:
> Has anyone proven a theorem saying that no such bugs exist in dash
> (zsh, ksh, etc.)?
Oh, "such bugs" really only exist in bash. I believe no other shell
processes an env var with a magic token into a function definition.
On Fri, Sep 26, 2014 at 6:06 AM, Leonid Isaev wrote:
>
>> Is there anything preventing us from making the switch from bash to dash
>> as /bin/sh now? We can then have dash provide sh instead.
>
> Yes -- due to the same reasons.
Care to elaborate?
Is there a wiki page tracking progress on this, or
With the disclosure of the new bash bug (CVE-2014-6271, CVE-2014-7169),
it seems timely to bring this up.
Dan added dash to core/base around seven years ago [1], intending the
eventually link /bin/sh to dash instead of bash.
[1]
https://mailman.archlinux.org/pipermail/arch-dev-public/2007-Novemb
On Mon, Sep 15, 2014 at 1:59 AM, tlux wrote:
> Thank you for your constructive reply.
Is this sarcasm? I do think beta software can be destructive, though.
On Mon, Sep 15, 2014 at 1:38 AM, Manolo Martínez
wrote:
> From the manual (which I did read prior to asking):
>
> "When ncmpcpp starts, it tries to read user's keybindings from
> ~/.ncmpcpp/keys file. If no user's keybindings is found, ncmpcpp uses
Ah, you use ~/.ncmpcpp/bindings instead no
On Mon, Sep 15, 2014 at 12:14 AM, tlux wrote:
> - the key bindings functionality has been redesign so as to use a bindings
> file located at /usr/share/doc/ncmpcpp which may be copied to your
> $XDG_CONFIG_HOME directory and then amended to suit your needs.
Except ncmpcpp does not use X
On Wed, Sep 10, 2014 at 6:25 PM, Guillaume ALAUX
wrote:
> On 9 September 2014 12:25, lolilolicon wrote:
>> To be sure, I do appreciate your effort, Guillaume. No one likes to deal
>> with this java crap. I don't have strong objections against your general
>> appr
On Tue, Sep 9, 2014 at 4:27 PM, Guillaume ALAUX wrote:
>
> Hello,
>
> Guillaume here (packager of that "piece of crap" java-common).
Yes it is pretty crappy.
>> symlinks created by the jre* packages at install time, without any
>> package tracking them.
>
> Yes, that is the point of script archl
On Tue, Sep 9, 2014 at 9:49 AM, lolilolicon wrote:
> Jesus, the java-common package is such a piece of crap. For one, all
> those links should be in the list of its tracked files.
This situation is worth some eye balls; I filed a bug here:
https://bugs.archlinux.org/task/41883
For anyo
Jesus, the java-common package is such a piece of crap. For one, all
those links should be in the list of its tracked files.
On Tue, Sep 9, 2014 at 8:42 AM, Thorsten Jolitz wrote:
>
> Hi List,
>
> after updating yesterday java does not work anymore for me:
>
> ,
> | [tj@arch ~]$ LC_ALL=C java --help
> | /usr/bin/java: line 2: /usr/lib/jvm/default/bin/java: Too many levels of
> | symbolic links
> | /usr/bin/java: lin
On Thu, Aug 21, 2014 at 1:39 PM, Yamakaky wrote:
> Hi
>
> It's good to have a real vim package, but the `clipboard` option is now
> disabled (see `vim --version`). Is there any reason ? I use it a lot via the
> "+ register.
If the use case is not too advanced, just use the clipboard
capabilities
On Mon, Jul 7, 2014 at 12:23 AM, Ralf Mardorf
wrote:
> On Sun, 2014-07-06 at 21:16 +0800, lolilolicon wrote:
>> for i in $(seq 97 122); do
>> printf "\x$(printf %x $i)\n"
>> done
>
> $ bash seq-dash
> a
> b
> [snip]
> x
> y
> z
> $ da
On Sun, Jul 6, 2014 at 8:52 PM, Karol Blazewicz
wrote:
>
>
> You can use
>
> echo $(seq -s '' 1 9)
>
> for number sequences, but I don't think you can do it with letters.
Following this line of thought, one can combine seq with printf to
produce {a..z}:
for i in $(seq 97 122); do
printf "\x$(p
On Wed, Aug 7, 2013 at 8:51 PM, Allan McRae wrote:
>
> Given it does not matter, there is no preference (at least from me).
>
Effectively true, but conceptually I think I would prefer an explicit
slash, which does not rely on the implicit $PWD == /.
Take again the example from my original email,
On Wed, Aug 7, 2013 at 6:19 PM, Allan McRae wrote:
>
> I believe it possibly did in the past, but pacman chroots into the
> --root directory before running any scripts so it makes no difference.
That's great, seeing that there're so many packages on both sides.
Is a leading slash preferred, then?
Many install scriptlets include the leading slash in file paths, e.g.
post_install() {
update-desktop-database -q
gtk-update-icon-cache -q -t -f /usr/share/icons/hicolor
}
while some strip the leading slash,
post_install() {
update-desktop-database -q
gtk-update-icon-cache -q -t
On Tue, Sep 6, 2011 at 4:54 PM, Thomas Bächler wrote:
> Am 06.09.2011 07:44, schrieb Westley Martínez:
>> I don't think my previous email went through. I apologize and disregard
>> if it did. Here is the original message:
>
> This symlink has been created in PKGBUILD for as long as our history
>
On Tue, Sep 6, 2011 at 3:51 PM, lolilolicon wrote:
>
> It's a symlink /bin/compress -> gzip. I assume the gzip binary is
> intended to behave as `compress` when it's called as `compress`.
> Yet it fails to do so, i.e. it's a bug in gzip, IMO.
Hmm, according t
On Tue, Sep 6, 2011 at 1:44 PM, Westley Martínez wrote:
> I don't think my previous email went through. I apologize and disregard
> if it did. Here is the original message:
>
> - Forwarded message from Westley Martínez -
>
> Date: Sun, 4 Sep 2011 00:44:46 -0700
> From: Westley Martínez
On Sat, Aug 6, 2011 at 11:16 PM, Bernardo Barros
wrote:
> If they have just this kernel, how they will boot the machine in order
> to fix it?
>
They can just edit the boot menu entry (Press `e' in the case of GRUB).
There're also Live CDs to rescue unbootable systems.
Thomas +1
On 07/20/11 at 12:46pm, Paul Gideon Dann wrote:
> On Wednesday 20 Jul 2011 08:41:43 Daniel Hilst Selli wrote:
> > I trying to set a ssh proxy.. For tests matter I'm using my local
> > desktop, as I can change sshd configurations all in one place
> >
> > I do this:
> > http://pastebin.com/g26A9imj
On 03/18/10 at 02:17am, David C. Rankin wrote:
> Guys,
>
> I just attempted an update which installed kernel26 2.6.32.10-1 on my
> x86_64
> box. After the update, the box failed to boot and the boot process stopped at
> the initrd/initramfs. (I have the slash because I can't remember the ex
31 matches
Mail list logo
