Re: [arch-general] End of official PaX and grsecurity support in Arch Linux

[Daniel Micay via arch-general]

On Mon, 2017-05-01 at 12:34 +, Alexander Harrigan wrote:
> It looks Gentoo's Hardened Kernel Project oficially started.
> 
> https://wiki.gentoo.org/wiki/Hardened/Hardened_Kernel_Project

Gentoo wiki page != Gentoo project.

signature.asc
Description: This is a digitally signed message part

Re: [arch-general] End of official PaX and grsecurity support in Arch Linux

[Daniel Micay via arch-general]

It isn't a contradiction. If the focus is on an LTS, then it's a dead
end and there will be nothing to show for it in the future. The easiest
time to start deciding what to drop and porting forward is now while
it's only one kernel version behind.

signature.asc
Description: This is a digitally signed message part

Re: [arch-general] End of official PaX and grsecurity support in Arch Linux

[Daniel Micay via arch-general]

On Sat, 2017-04-29 at 17:03 +, Alexander Harrigan wrote:
> I found someone from opensuse started to maintain grsec patches for
> 4.9 kernel
> series [1]. Maybe it will be possible to add linux-lts-grsec package
> to AUR
> based on Daniel's PKGBUILD and config with RANDSTRUCT enabled linked
> to new
> upstream source.
> 
> [1] https://github.com/kdave/grsecurity-patches/tree/master/wip

As I mentioned, it can't be called PaX or grsecurity. I also don't think
it makes sense to expend time on this. It won't support new hardware and
systemd will probably increase the minimum kernel version before the 4.9
LTS is end-of-life. Effort spent on 4.9 is effort not spent on anything
that will actually last. If someone decides to do this, they'll also be
taking responsibility for maintaining PaX exceptions, etc. and handling
any bugs caught by the features or false positives. There will be new
issues introduced as the LTS gets changes backported to it.

signature.asc
Description: This is a digitally signed message part

Re: [arch-general] End of official PaX and grsecurity support in Arch Linux

[Daniel Micay via arch-general]

On Thu, 2017-04-27 at 20:45 +, Alexander Harrigan wrote:
> It would be great if you can provide linux-hardened kernel with
> everything
> what KSPP has enabled by default. Even in AUR so you won't have to
> rebuild it
> constantly and random stack option would have more sense.
> 
> Two questions:
> 
> 1\. Do you think maintaining 4.9 lts grsec kernel would be doable
> until it
> gets EOL from upstream?

That could be done, but it can't be called grsecurity or PaX anymore.

There will be conflicts when applying the new patches. There will be
real bugs that are caught by the mitigations and also some cases that
are false positives or just benign issues that upstream doesn't consider
to be a bug from features like SIZE_OVERFLOW. There is no longer an
upstream (i.e. PaX and grsecurity) where these issues can be reported.

For it to be officially packaged again, there needs to be a very
competent upstream taking responsibility for everything as there was
before.

I don't really think it makes sense to track 4.9 until it dies. It's a
dead end and new security features will be landing in mainline.

I think it makes sense to have a linux-hardened package but I can't
currently commit to doing that. I need to think about it over the next
few days.

It would also make sense to have a substantially stripped down fork,
dropping everything that can be provided via upstream features, modern
hardware (SMAP on Broadwell or later) or SELinux and just hoping that
people work on having great SELinux support as an orthogonal project. I
really don't have time for that though. It needs to be a collaborative
effort, and I really do mean collaborative i.e. *multiple* people doing
a substantial amount of difficult work and making hard decisions about what 
should be dropped to keep it maintainable. For example, some may see dropping 
UDEREF for x86_64 and just assuming SMAP is present to be too unfriendly to 
people with legacy hardware, but NOT doing that as much as possible means so 
much extra very complex code to maintain. I have no interest in maintaining 
code for legacy hardware that I don't use or being blocked by porting it to new 
kernel versions.

> Are there many incompatible changes with minor kernel
> releases? I heard gentoo (maybe debian?) are considering this.

Plenty. It's very realistic to do that, but there's still work. The main
issue is that there isn't going to be an end to upstream bugs and false
positives being found, just fewer if it's frozen at 4.9 and destined to
die off as it ages.

> 2\. Why hidepid was removed? I saw "lack of time" comment but...there
> wasn'tmuch to maintain as it worked flawles for long time.

A bug was reported where it caused problems booting. Multiple people
stated that they hit it, so I believe that it's real. I don't have time
to look into it and no one else was doing that, so I replaced it with
documentation on doing it manually on the wiki:

https://wiki.archlinux.org/index.php/Security#hidepid

It was nice having the package, but if there's something broken and no
one is addressing that I'm not going to keep it around.

signature.asc
Description: This is a digitally signed message part

Re: [arch-general] End of official PaX and grsecurity support in Arch Linux

[Daniel Micay via arch-general]

On Thu, 2017-04-27 at 19:12 +, Carsten Mattner wrote:
> Is CopperheadOS using grsec or something derived from it?

It starts from the baseline provided by Google and ports features from
PaX and grsecurity as needed to the kernels. It used to use a full PaX
port on ARM devices but that hasn't made sense for quite some time.

Android is much a different target. CopperheadOS is starting from a base
system that's already quite hardened. PaX / grsecurity kernel self
protection features are applicable to Android but the bulk of them don't
support arm64 in grsecurity at the moment so it's no use beyond as a
source for porting / inspiration. The features that landed upstream
ended up being ported to arm64. The grsecurity test patches becoming
private has no impact on CopperheadOS. There's a significant indirect
impact in that the source of 95% of Linux kernel security research /
innovations is now no longer publicly available. KSPP no longer has an
incredible source to copy ideas and code from and neither do we.

grsecurity RBAC and all but a few of the miscellaneous features aren't
relevant to Android. It already has the baseline per-user, per-app
uid/gid separation reinforced with a full system SELinux policy that's
far beyond what RHEL / Fedora provide, since there's a well-defined base
system (no system administrator choosing packages / configuration) and a
well-defined app sandbox for all third party code. Devices handle their
drivers and hardware-specific services/libraries via device-specific
policy extensions. For example, SELinux ioctl filtering is used for
kernel attack surface reduction by whitelisting ioctl commands per-
device including whitelisting only the set of GPU driver ioctl commands
used by the device in practice. They're also making increasingly good
use of seccomp-bpf.

Even some of the most basic security features like full verified boot
for the whole OS and always enabled encryption are pipe dreams for
traditional distributions. Android's linker doesn't support non-PIE and
text relocations are only supported for legacy API level 32-bit apps.
Full RELRO, strong SSP and _FORTIFY_SOURCE=2 (beyond what glibc
provides) are globally enabled.

The AOSP kernels are very minimal, i.e. no modules enabled and only a
small set of drivers, etc. needed for the platform. Features like System
V IPC and now AIO aren't enabled. Google already has KSPP features
backported and enabled in their LTS kernels like HARDENED_USERCOPY
(incomplete KSPP implementation of PaX USERCOPY), __ro_after_init
(incomplete KSPP implementation of PaX __read_only) and PAN (UDEREF
equivalent) emulation for ARM and ARMv8.0 where PAN isn't yet available.
They also have kernel security features that were rejected upstream like
perf_event_paranoid=3 which we upstreamed to AOSP.

In addition to that much different starting point, CopperheadOS also has
full control of the entire base system. There's a unified build system
and all of the sources are in one tree like a *BSD OS. It's so much
different than trying to deal with bringing desktop Linux security on
par with 2008 security standards, which is still so far away as a goal.
One day perhaps flatpak / wayland will have caught up to providing a
basic security model for desktop Linux and some day Arch will finally
get PIE enabled by default but all of those kind of things are already
provided by the baseline OS that CopperheadOS starts from.

signature.asc
Description: This is a digitally signed message part

Re: [arch-general] End of official PaX and grsecurity support in Arch Linux

[Daniel Micay via arch-general]

On Thu, 2017-04-27 at 19:11 +, Carsten Mattner wrote:
> This is an undesirable situation for users, but I want to offer a
> positive outlook on this. Ever since KSPP started, some of the
> dynamics started to shift and I wager that closing off grsec will
> motivate more users and developers to consider supporting efforts that
> are in mainline linux. Short-term this is a problem and may require
> relying and hoping 4.9-lts-grsec will be available and functioning.
> When Bitkeeper licensing was revoked from the community, it didn't
> take long for git to emerge. I see a similar pattern and high
> potential for repetition of the same dynamics here. No grsec will
> force people to either subscribe ala RHEL and hope spender is able to
> fulfill his end of the contract or supporting KSPP and seamless LSM
> integration in major distro packages.

It's primarily not a technical issue, it's a political ones. As part
landing mitigations upstream, they end up being watered down into
slower, incomplete and/or weaker implementations. Lots has been outright
rejected. Software implementations of SMEP and SMAP are not happening
for i386 and x86_64. Proper slab sanitization was rejected. Proper page
sanitization was rejected. RAP and SIZE_OVERFLOW upstream are pipe
dreams. The REFCOUNT mitigation was rejected and is going to need to be
done as opt-in, but they also blocked an efficient implementation like
PaX and opt-in usage was rejected in the network stack, etc. due to the
performance cost of their crappier implementation. A new refcount_t
implementation may land, but there are a lot of politics involved and
landing a migration from atomic_t to refcount_t across the kernel is
going to be insanely slow and difficult. It has to be submitted bit by
bit to different maintainers... and that's only the tip of the iceberg
for these mitigations.

It's realistically going to take 5+ years for KSPP to land everything
other than RAP and SIZE_OVERFLOW and that's assuming it's extremely
successful and the political issues are overcome. UDEREF/KERNEXEC will
never land in their entirety and PaX and grsecurity are quickly moving
targets. RAP didn't exist until recently, and it's now the flagship
mitigation they offer. KERNSEAL/STRUCTGUARD won't have public code to
copy... and neither will all of the other new stuff. No one else is
doing compelling new kernel security research... so what happens once
there's no longer public code to copy? It's literally a copy-paste job
right now with bikeshedding of naming and kernel politics, and yet it's
still going poorly. KSPP is quite useful and is improving things, sure.
It's a joke to claim that it's going to be comparable to grsecurity
though.

> I must admit that spender may have started a process that will result
> in arriving quicker at mainline kernel having a comparable set of
> protections. Because as long as grsec was there and offered for
> relatively recent kernels, there wasn't much motivation or arguments
> to make to support a mainline reimplementation.
> 
> I believe this will light a fire under KSPP and related community
> driven projects.

I can't see it going any faster than it already is, which is slow
progress towards landing some things, with lots of setbacks and
crippling of the features to make them acceptable upstream. I don't
think there's any hope of landing mitigations like SIZE_OVERFLOW and RAP
any time in the near future. RAP requires sweeping fixes of undefined
behavior across the kernel, along with changes to calls/returns in all
of the assembly code. SIZE_OVERFLOW is similar, but also requires many
fixes of non-bugs. The only changes that have been successful landed
upstream are those that are quite contained, or bits and pieces of ones
that make wider changes in areas where the maintainers are active and
see the value of it. Familiarity with what's actually happening and has
happened already is needed to make any useful predictions about it.

> I faintly remember when there was OpenGrsec because grsec was dead or
> zombie but that was at least a decade ago and my memory is probably
> incomplete.

I can't find anything about that via searching for it. The grsecurity
patches are also a lot different in terms of what they contain now
compared to a decade ago. PaX started from NX emulation, inventing ASLR
and other userspace mitigations but then ended up being focused on
kernel self-protection and grsecurity similarly has a much different
focus than it did in the past. They're much bigger today and they have a
lot of complex, arcane code for architecture-specific mitigations.

> I mean some grsec users might consider fleeing to HardenedBSD since
> they provide a whole system like Hardened Gentoo, especially those
> using grsec on hosting servers where the availability of jails,
> capsicum, zfs, dtrace, ports and hardenedbsd may have already looked
> enticing.

HardenedBSD doesn't provide most of the grsecurity mitigations,
including some of the most important / 

[arch-general] End of official PaX and grsecurity support in Arch Linux

[Daniel Micay via arch-general]

The PaX and grsecurity patches are no longer going to be public, so
official support in Arch Linux has ended:

https://grsecurity.net/passing_the_baton.php
https://grsecurity.net/passing_the_baton_faq.php

I'll be clearing out the AUR packages for PaX and grsecurity soon since
the current 4.10 patches are not accessible. Providing out-of-date
packages with known vulnerabilities and without the current set of
mitigations is infringing on how they want their trademarks used. If
people want to maintain forks, either a 4.9 LTS or porting it forward to
newer kernels, they'll need to make a new project with a new name rather
than using "PaX" or "grsecurity" as the naming. If it's serious and done
by people that know what they're doing, official support for it can be
considered. There are few people that are capable of truly taking over
maintenance of the whole patches and I expect that they won't have time
to do it. Don't be optimistic about this happening.

There are no viable alternatives to PaX and grsecurity. Their focus is
on kernel self-protection i.e. protecting the kernel from exploits, and
we don't have anything for users to migrate to from these. There are
plenty of alternatives to grsecurity RBAC but that's only a small
portion of what the patches provide. Any form of access control (whether
it's MAC, containers, uid/gid separation, ACLs, etc.) can be entirely
bypassed with a single kernel exploit, so the only good way to use other
MAC implementations like TOMOYO, AppArmor or SELinux was with
grsecurity. We don't actually provide official support for any of these
alternatives, but it's all little good without a hardened kernel anyway.

A small subset of the kernel self-protection features have landed
upstream as part of the Kernel Self Protection Project. The core/linux
package doesn't enable the bulk of these features, and it probably
doesn't make sense for it to turn everything on because a subset of them
 do have a significant performance cost. It would be possible to provide
a linux-hardened package doing that but it would only offer a tiny
portion of the kernel self-protection that grsecurity does. I may end up
doing that, along with enabling support for all of the LSMs, etc. there
but it's really not at all comparable to what has been lost. The LSMs
are also little good without people working on providing userspace
integration and policies for them.

There are no good answers here. It would be possible to maintain a fork
of grsecurity, especially if all kernel architectures other than x86_64
(and arm64, but it's not currently supported) were dropped along with
grsecurity RBAC and anything that has a proper equivalent upstream. i386
and armv7 can still be supported as userspace archs, since dropping them
as kernel archs is what would save most of the maintainance work and
would eliminate a bunch of complex code only currently fully understood
by the PaX and grsecurity authors. It might also make sense to start
dropping support for old CPUs, beyond just only supporting 64-bit
kernels. Intel Broadwell and later provide SMAP and there's also SMEP,
so those could be used as substitutes for UDEREF and that portion of the
KERNEXEC feature.

The problem is that there aren't capable people with the time and
willingness to dedicate a huge amount of their time to a volunteer
project without pay. I already maintain/develop hardened Android LTS
kernels as a significant but overall quite small part of CopperheadOS.
It's not comparable to this because it's my job. I spend far more than
40 hours a week on CopperheadOS, and it's actually quite a relief to not
need to worry about maintaining PaX and grsecurity for Arch Linux
anymore especially since I had to do it on my own. I've been aware that
the test patches becoming private was a very real possibility even
before spender started talking about it on IRC weeks ago, so it's really
not a surprise.

signature.asc
Description: This is a digitally signed message part

Re: [arch-general] Revisiting the SELinux/audit question: Disabling audit on the kernel command line

[Daniel Micay via arch-general]

On Mon, 2017-02-13 at 16:18 +0100, Tobias Markus wrote:
> On Sun, 2017-02-12 at 23:13 +0100, Nicolas Iooss wrote:
> > On Sun, Feb 12, 2017 at 6:43 PM, Tobias Markus 
> > wrote:
> > 
> > > Hi,
> > > 
> > > As some of you might know, the question of enabling SELinux
> > > support in
> > > the official Arch Linux kernel package has been brought up a
> > > number of
> > > times. The main issue that has been pointed out the previous time
> > > was
> > > that enabling SELinux depends on CONFIG_AUDIT which is considered
> > > unnecessary or even harmful for most desktop users since it
> > > generates a
> > > flood of kernel log messages.
> > > 
> > 
> > Hi,
> > Do you have more information about this unwanted flood of messages?
> > From my
> > personal experience on systems with SELinux and audit, the
> > application
> > which produces the biggest number of audit events is Chromium,
> > because of
> > misconfigured seccomp rules that report in audit log every call to
> > set_robust_list(). This has been reported two years ago on Chromium
> > bug
> > tracker and the developers seem unwilling to fix it (
> > https://bugs.chromium.org/p/chromium/issues/detail?id=456535). If
> > there are
> > similar problems which need to be fixed before thinking of enabling
> > audit
> > compilation in Arch Linux kernel, where can I find information on
> > them?
> > 
> > Regards,
> > Nicolas
> 
> Hi Nicolas,
> 
> I have also seen a flood of audit messages arising from Chromium.
> However, the configuration I propose would not actually enable audit
> by default,
> i.e. unless you explicitly set "audit=1" in the bootloader's kernel
> command
> line, the audit subsystem will be disabled and thus silent. In other
> words, if
> you don't want to use SELinux/audit, the impact should be minimal.
> 
> Since the Chromium bug you mentioned is an application bug, I don't
> think it
> should hinder enabling the audit option, especially since audit would
> be opt-in.

It's not a bug. It's intentional hardening... and is correct.

> The reason for Chromium's message floods is that Chromium create quite
> a lot of
> processes and (as written in the bug report you mentioned)
> set_robust_list is
> called during that. So floods of audit messages should be rather
> atypical.
> 
> Greetings
> Tobias

signature.asc
Description: This is a digitally signed message part

Re: [arch-general] sandboxing

[Daniel Micay via arch-general]

On Fri, 2017-02-03 at 17:49 +0100, Bart De Roy via arch-general wrote:
>   Error verifying signature: parse error
> --pyi53mwzyx2s2ll6
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> 
> hello
> 
> I've been postponing looking into browser isolation
> since I started using Wayland about a year ago.
> 
> Does anyone have pointers, experiences or comments on
> this topic with regard to Xwayland? If I'd want to
> disassociate parts of chromiums execution context,
> what are common, good options?
> 
> cheers, Bart
> 
> --pyi53mwzyx2s2ll6--

The vast majority of Chromium's code already runs in far tighter
sandboxes than can be made externally via namespaces, MAC, etc.

Using an outer sandbox can help in the case where a sandbox bypass
exploits the browser's broker process responsible for managing the
renderers. The easiest way out is often a kernel exploit despite the
extremely restricted system call whitelist which doesn't even include
calls like open(...). If you want to strength the existing sandbox, a
hardened kernel goes a long way to mitigating one of the two primary
attack vectors for escaping the sandbox.

There might be some value in containing the file access of the outer
sandbox even if it's not really contained, because an attacker might
only be able to influence it to incorrectly open any file, etc. if they
only have code execution in a renderer without a code execution exploit
for the outer part. I don't think there have been many bugs like that
though, it's mostly just a full sandbox escape in which case the outer
sandbox would actually need to contain usage of X11, pulseaudio, dbus,
etc. So you definitely need more than simply MAC or namespaces + X11 /
pulse access granted. Indirect access to X11 via another instance of it
isn't great either.

signature.asc
Description: This is a digitally signed message part

Re: [arch-general] user namespaces

[Daniel Micay via arch-general]

On Thu, 2017-02-02 at 19:32 +0200, Francisco Barbee wrote:
> 
> So your advice for now would be to use grsecurity
> kernel and forget all those jails and namespaces
> until someone figure out proper security solution?

I never said that...

It simply doesn't make sense to base application sandboxes on user
namespaces. That's all. Isolation can be exposed to unprivileged users
without that insanity.

Chromium has the best sandbox available for large applications like
that, and it works fine without user namespaces. The tiny setuid binary
barely adds attack surface vs. the enormous fully privileged attack
surface of user namespaces. The chrome-sandbox binary can be contained
by MAC too, if you use it.

signature.asc
Description: This is a digitally signed message part

Re: [arch-general] user namespaces

[Daniel Micay via arch-general]

On Thu, 2017-02-02 at 17:39 +0100, Ralf Mardorf wrote:
> On Thu, 02 Feb 2017 11:22:28 -0500, Daniel Micay via arch-general
> wrote:
> > The reason for SELinux and AppArmor not being enabled for linux or
> > linux-grsec has to do with audit. If people were willing to do a bit
> > of work, all of the MAC implementations rather than only grsecurity
> > RBAC and TOMOYO could be available.
> 
> IIUC Mark Shuttleworth offered manpower to enable a standard mac-based
> security framework:
> https://lists.ubuntu.com/archives/snapcraft/2017-January/002247.html

There's a need to improve audit or remove the dependency on it. If there
was a kernel configuration option upstream to fully disable audit by
default and avoid logging / performance / security issues from it then
the kernel maintainers would likely be willing to enable it and the LSMs
depending on it again. They were disabled due to the drawbacks of audit,
 combined with the lack of effort to actually use those LSMs on Arch. It
is not simply a matter of people not stepping up to integrate the MACs
but also the kernel requiring changes that our kernel maintainers are
not willing to carry out-of-tree.

signature.asc
Description: This is a digitally signed message part

Re: [arch-general] user namespaces

[Daniel Micay via arch-general]

On Thu, 2017-02-02 at 16:29 +0100, sivmu wrote:
> 
> Am 02.02.2017 um 11:28 schrieb Daniel Micay via arch-general:
> > On Thu, 2017-02-02 at 02:40 +0100, sivmu wrote:
> > > 
> > > Am 01.02.2017 um 21:21 schrieb Daniel Micay via arch-general:
> > > > > > it's a nearly useless feature. 
> > > > > 
> > > > > That's a baseless claim, that was already proved wrong in my
> > > > > first
> > > > > post
> > > > > by the many applications that use this feature.
> > > > 
> > > > That doesn't demonstrate that it's useful relative to the
> > > > alternatives.
> > > > It enables unprivileged OS containers but isn't really any use
> > > > for
> > > > app
> > > > containers.
> > > > 
> > > 
> > > Pretty much all famous container programms use this. I wonder why
> > > if
> > > there is no use for it.
> > > 
> > > Also I would still like to see a simple alternative for
> > > unprivileged
> > > namespaces to sandbox apps.
> > > How do you provide something like bubblewrap without user
> > > namespaces?
> > > And no that android example below is not the same as long as there
> > > is
> > > no
> > > simple way to use this (which I am not aware of)
> > 
> > Doing things properly is not easy.
> > 
> 
> That's a bad attitude. It sounds like proper implementations need to
> be
> difficult. That's not true. Especially security and above all crypto
> fails often because it is hard to apply. That is why people like Bruce
> Schneier have often talked about this. Dan Bernstein has created the
> crypto library NaCl for that very reason, to allow the use of crypto
> without overly complex and error prone implementations like needed by
> openssl.
>
> That is why this sentence is extremly wrong and dangerous.
> If there is no way to privide users or developers with easy tools to
> sandbox apps, then one has to be created. Just saying that doing
> things
> properly isn't easy will do more harm then features like user
> namespaces
> will ever be able to.

Stop misrepresenting my position and arguing against strawmen. Providing
easy tools to sandbox applications is important. Those tools should be
robust and secure, which is the part that's not easy. That's clearly
what I was talking about, but you're only interested in trying to score
points without actually trying to understand but simply regurgitating
talking points without having a clue. User namespaces are not at all
necessary for providing unprivileged sandboxing. For example, SubgraphOS
doesn't use user namespaces.

You're the one doing harm, by wasting time and hurting the chances of
someone actually getting what you want done. User namespaces had a
higher chance of being enabled before you showed up, just like what
happened with moving away from using md5/sha1 for hashes in PKGBUILDs
and what happened with MAC.

> And if I am not mistaken, that is pretty much what android does: it
> provides app developers with easy ways to drop privileges and sandbox
> their apps.
> 
> Therefore I think the wish and need for easy ways to privode security
> is
> important.
> 
> Bubblewrap is one of the concepts that I think do a great job on
> providing easy isolation of apps, even if they utilise namespaces for
> that purpose. (The Tor people seem to agree)

Another argument to authority? Tor tries to build a privacy-oriented
browser on top of by far the least secure mainstream browser. Tails
doesn't (currently) even use a PaX / grsecurity kernel despite it being
fairly easy to integrate particularly for a distribution like that. It
doesn't use a full system MAC policy either. Is that really the ivory
tower you're looking to for advice?

> > > > > > but no one really wants it for that reason. They
> > > > > > want it because it started pretending that it can offer
> > > > > > something
> > > > > > that
> > > > > > it can't actually deliver safely.
> > > > > 
> > > > > Again a claim without prove
> > > > 
> > > > The proof is easy to find. You're the one making a proposal but
> > > > you
> > > > clearly haven't done your research. It's not my job to spoon
> > > > feed
> > > > you.
> > > > 
> > > 
> > > I do know some of the discussions about this feature on the kernel
> > > mailing list. But the opinions even there are not as clear as you
> > > want
> > > to make us believe.
> > 
> > The ke

Re: [arch-general] user namespaces

[Daniel Micay via arch-general]

On Thu, 2017-02-02 at 17:06 +0200, Francisco Barbee via arch-general
wrote:
> So what's your alternatives/setup usable on Arch
> (not android, not ChromeOS)? We heave disabled
> SElinux, disabled Apparmor, disabled user
> namespaces, PIE not enabled by default and only
> partial relro. What's left then? Swimming naked?

You're venturing totally off-topic here, but I'll respond anyway.

The intention is to enable PIE by default but no one is stepping up to
help Allan with it. There are binutils test failures that need to be
triaged, and either fixed or ignored if they are not real failures.

Arch has a hardened linux-grsec kernel package which offers multiple MAC
options enabled. The reason for SELinux and AppArmor not being enabled
for linux or linux-grsec has to do with audit. If people were willing to
do a bit of work, all of the MAC implementations rather than only
grsecurity RBAC and TOMOYO could be available. I don't see much value in
a huge amount of choice here anyway. None of it is particularly relevant
to sandboxing desktop applications due to X11, pulseaudio, dbus, etc. In
theory Wayland was supposed to be forward progress on that front but it
depends on the Wayland compositor choosing to provide a real security
model.

Unprivileged access to user namespaces is an anti-security feature, not
a security feature. User namespaces themselves offer essentially zero
value to application containers. The uid/gid mapping is superfluous when
using a different approach and it isn't even properly supported since
there's so much missing. The distribution would be significantly less
secure with them enabled for unprivileged use. You should be thankful
that the feature is not exposed by default if you really care about
security rather than just being a concern troll.

signature.asc
Description: This is a digitally signed message part

Re: [arch-general] user namespaces

[Daniel Micay via arch-general]

On Thu, 2017-02-02 at 02:40 +0100, sivmu wrote:
> 
> Am 01.02.2017 um 21:21 schrieb Daniel Micay via arch-general:
> > > > it's a nearly useless feature. 
> > > 
> > > That's a baseless claim, that was already proved wrong in my first
> > > post
> > > by the many applications that use this feature.
> > 
> > That doesn't demonstrate that it's useful relative to the
> > alternatives.
> > It enables unprivileged OS containers but isn't really any use for
> > app
> > containers.
> > 
> 
> Pretty much all famous container programms use this. I wonder why if
> there is no use for it.
> 
> Also I would still like to see a simple alternative for unprivileged
> namespaces to sandbox apps.
> How do you provide something like bubblewrap without user namespaces?
> And no that android example below is not the same as long as there is
> no
> simple way to use this (which I am not aware of)

Doing things properly is not easy.

> > > > but no one really wants it for that reason. They
> > > > want it because it started pretending that it can offer
> > > > something
> > > > that
> > > > it can't actually deliver safely.
> > > 
> > > Again a claim without prove
> > 
> > The proof is easy to find. You're the one making a proposal but you
> > clearly haven't done your research. It's not my job to spoon feed
> > you.
> > 
> 
> I do know some of the discussions about this feature on the kernel
> mailing list. But the opinions even there are not as clear as you want
> to make us believe.

The kernel configuration disables it by default. It enables UTS, IPC,
PID and NET namespaces by default. That's the opinion from upstream on
the sane default for a general purpose build: disabled.

It is quite clear that it's a major security risk. It exposes an endless
stream of privesc vulnerabilities from all of the attack surface it
adds. That attack surface was never exposed like that before and the
code is not at all robust against attackers, since it was only exposed
to root users before. It is going to take years for it to settle down
and become more like core kernel code that was already exposed, and it's
always going to be a ton of extra attack surface.

> > > > There are much better ways to do
> > > > unprivileged sandboxes with significantly less risk than
> > > > CLONE_NEWUSER
> > > > or setuid executables where the user controls the environment.
> > > 
> > > And yet you fail to name even one alternative. Please do
> > 
> > Uh, yeah, I did. M
> > 
> 
> Sorry but 'M' ? I don't get it.
> 
> > > > Anything
> > > > depending on this mechanism instead of properly designed
> > > > plumbing
> > > > for it
> > > > is simply lazy garbage.
> > > 
> > > Another baseless and arrogant claim
> > 
> > Not baseless and it's not arrogant to point out that this is a bad
> > feature for app containers. It's the truth.
> 
> even if that is correct, it is a pretty weird/funny argument to say
> it's
> the truth ... :)
> 
> 
> > > > There's still an unrelenting torrent of security issues from
> > > > it. 
> > > 
> > > Name one
> > 
> > Look at the discussion on the issue report or do basic research on
> > the
> > topic. It's your proposal, if you haven't done even basic research
> > that's your problem.
> 
> I did, but we differ about the interpretations (see below)
> 
> 
> > 
> > > > Maybe wait until that stops before proposing this. 
> > > 
> > > Vulnerabilities in kernel features will never stop to exist. If we
> > > disable everything with potential vulnerabilities, we did not have
> > > a
> > > kernel anymore.
> > 
> > It's a very niche feature with better alternatives for sandboxes and
> > app
> > containers. It exposes all of the netfilter administration code and
> > tons
> > of other networking and mount code as new attack surface.
> 
> Point taken
> 
> 
> > > 
> > > Android uses minijail (default app sandbox in android 7), which
> > > relies
> > > on user namespaces…
> > > Just opened a terminal on my android and checked it. Its inside a
> > > user
> > > namespaces.
> > 
> > No, that's incorrect and you're just further demonstrating how far
> > out
> > of your depth you are here. Google doesn't even enable user
> > namespaces
> > in the kernel in AOSP / stock Android for Nexus/Pixel. Doubt that
> > 

Re: [arch-general] user namespaces

[Daniel Micay via arch-general]

On Wed, 2017-02-01 at 19:51 +0100, sivmu wrote:
> 
> Am 01.02.2017 um 07:20 schrieb Daniel Micay via arch-general:
> > On Wed, 2017-02-01 at 00:18 +0100, sivmu wrote:
> > > Summary:
> > > 
> > > Arch Linux is one of the few, if not the only distribution that
> > > still
> > > disables or restricts the use of unprivileged user namespaces, a
> > > feature
> > > that is used by many applications and containers to provide secure
> > > sandboxing.
> > > There have been request to turn this feature on since Linux 3.13
> > > (in
> > > 2013) but they are still being denied. While there may have been
> > > some
> > > reason for doing so a few year ago, leading to many distributions
> > > like
> > > Debian and Red Hat to restrict its use to privileged users via a
> > > kernel
> > > patch (they never disabled it completely), today arch seems to be
> > > the
> > > only distribution to block this feature. Even conservative distros
> > > like
> > > Debian 8 and 9 have this feature fully enabled.
> > 
> > There are still endless unprivileged user namespace vulnerabilities
> 
> 
> You failed to name even one.

I already listed several in the linked issue reports.

> > it's a nearly useless feature. 
> 
> That's a baseless claim, that was already proved wrong in my first
> post
> by the many applications that use this feature.

That doesn't demonstrate that it's useful relative to the alternatives.
It enables unprivileged OS containers but isn't really any use for app
containers.

> > The uid/gid mapping is poorly thought out
> > and immature without the necessary environment (filesystem support,
> > etc.) built around it, 
> 
> Something like mount namespaces, that are designed to be used in
> combination with user namespaces?

That has nothing to do with this.

> > but no one really wants it for that reason. They
> > want it because it started pretending that it can offer something
> > that
> > it can't actually deliver safely.
> 
> Again a claim without prove

The proof is easy to find. You're the one making a proposal but you
clearly haven't done your research. It's not my job to spoon feed you.

> > There are much better ways to do
> > unprivileged sandboxes with significantly less risk than
> > CLONE_NEWUSER
> > or setuid executables where the user controls the environment.
> 
> And yet you fail to name even one alternative. Please do

Uh, yeah, I did. M

> > Anything
> > depending on this mechanism instead of properly designed plumbing
> > for it
> > is simply lazy garbage.
> 
> Another baseless and arrogant claim

Not baseless and it's not arrogant to point out that this is a bad
feature for app containers. It's the truth.

> > Lack of a proper layer on top of the kernel
> > providing infrastructure (systemd is so far from that) on
> > desktop/server
> > Linux is not going to be fixed by delegating everything to the
> > kernel
> > even when it massively increases attack surface.
> > 
> > > I would like to suggest that arch stops to disable this feature in
> > > future kernel versions.
> > > 
> > > Resoning:
> > > 
> > > The original reason to block user namespaces were a number of
> > > security
> > > issues that allowed unprivileged users to access features they
> > > should
> > > not have access to. Due to the nature of user namespaces to
> > > provide
> > > isolated user environments with access to privileged features like
> > > other
> > > namespaces (inside that isolated namespace only), it should be
> > > obvious
> > > that this feature had to be designed carefully in order not to
> > > harm
> > > the
> > > security outside the namespace. Even though there have been
> > > issues,
> > > this
> > > feature is now considered stable enough for distros like debian
> > > and
> > > red
> > > hat to allow its use even for unprivileged users.
> > 
> > There's still an unrelenting torrent of security issues from it. 
> 
> Name one

Look at the discussion on the issue report or do basic research on the
topic. It's your proposal, if you haven't done even basic research
that's your problem.


> > Maybe wait until that stops before proposing this. 
> 
> Vulnerabilities in kernel features will never stop to exist. If we
> disable everything with potential vulnerabilities, we did not have a
> kernel anymore.

It's a very niche feature with better alternatives for sandboxes and

Re: [arch-general] user namespaces

[Daniel Micay via arch-general]

On Wed, 2017-02-01 at 00:21 -0700, Leonid Isaev wrote:
> On Wed, Feb 01, 2017 at 01:20:41AM -0500, Daniel Micay via arch-
> general wrote:
> > On Wed, 2017-02-01 at 00:18 +0100, sivmu wrote:
> > > Summary:
> > > 
> > > Arch Linux is one of the few, if not the only distribution that
> > > still
> > > disables or restricts the use of unprivileged user namespaces, a
> > > feature
> > > that is used by many applications and containers to provide secure
> > > sandboxing.
> > > There have been request to turn this feature on since Linux 3.13
> > > (in
> > > 2013) but they are still being denied. While there may have been
> > > some
> > > reason for doing so a few year ago, leading to many distributions
> > > like
> > > Debian and Red Hat to restrict its use to privileged users via a
> > > kernel
> > > patch (they never disabled it completely), today arch seems to be
> > > the
> > > only distribution to block this feature. Even conservative distros
> > > like
> > > Debian 8 and 9 have this feature fully enabled.
> > 
> > There are still endless unprivileged user namespace vulnerabilities
> > and
> > it's a nearly useless feature. The uid/gid mapping is poorly thought
> > out
> > and immature without the necessary environment (filesystem support,
> > etc.) built around it, but no one really wants it for that reason.
> > They
> > want it because it started pretending that it can offer something
> > that
> > it can't actually deliver safely. There are much better ways to do
> > unprivileged sandboxes with significantly less risk than
> > CLONE_NEWUSER
> > or setuid executables where the user controls the environment.
> > Anything
> > depending on this mechanism instead of properly designed plumbing
> > for it
> > is simply lazy garbage. Lack of a proper layer on top of the kernel
> > providing infrastructure (systemd is so far from that) on
> > desktop/server
> > Linux is not going to be fixed by delegating everything to the
> > kernel
> > even when it massively increases attack surface.
> 
> BTW, why can't one simply create a *privileged* lxc container on a
> host
> filesystem mounted with nosuid, then create an unprivileged user
> inside that
> container for browsing / viewing of untrusted pdfs, etc?

Application containers don't have a use for the user namespace quasi
root and no one really needs the half baked uid/gid mapping feature.
There's no real reason for stuff being done that way beyond desktop
Linux having the disease of inability to do plumbing in userspace, but
instead putting everything in the kernel simply to have it universally
available rather than for technical reasons.

It would make sense to simply have a service spawning on-demand unpriv
users from a range of uid/gid pairs. That's exactly how this works on
Android for both apps and isolatedProcess services (they each get a
unique uid/gid pair assigned), although they also layer SELinux and
mount namespaces on top.

The only real use case for user namespaces is unprivileged, contained
usage of OS containers since they actually need the quasi root. For
application containers / sandboxes, it's just laziness and bad design.

signature.asc
Description: This is a digitally signed message part

Re: [arch-general] user namespaces

[Daniel Micay via arch-general]

Also worth noting that one of the first thing any sandbox based on user
namespaces will do is *disabling* user namespaces. The programs using
them acknowledge them to be a huge security problem. It doesn't work out
well when only a subset of processes are running in that container env.

The only sane way to approach this without taking a different path is
implementing plumbing to only expose user namespaces to the sandbox
spawning executables. Kernel infrastructure exists for doing that
already. It just depends on whether anyone is willing to do any real
work vs. complaining about it and denying the facts.

signature.asc
Description: This is a digitally signed message part

Re: [arch-general] user namespaces

[Daniel Micay via arch-general]

On Wed, 2017-02-01 at 00:18 +0100, sivmu wrote:
> Summary:
> 
> Arch Linux is one of the few, if not the only distribution that still
> disables or restricts the use of unprivileged user namespaces, a
> feature
> that is used by many applications and containers to provide secure
> sandboxing.
> There have been request to turn this feature on since Linux 3.13 (in
> 2013) but they are still being denied. While there may have been some
> reason for doing so a few year ago, leading to many distributions like
> Debian and Red Hat to restrict its use to privileged users via a
> kernel
> patch (they never disabled it completely), today arch seems to be the
> only distribution to block this feature. Even conservative distros
> like
> Debian 8 and 9 have this feature fully enabled.

There are still endless unprivileged user namespace vulnerabilities and
it's a nearly useless feature. The uid/gid mapping is poorly thought out
and immature without the necessary environment (filesystem support,
etc.) built around it, but no one really wants it for that reason. They
want it because it started pretending that it can offer something that
it can't actually deliver safely. There are much better ways to do
unprivileged sandboxes with significantly less risk than CLONE_NEWUSER
or setuid executables where the user controls the environment. Anything
depending on this mechanism instead of properly designed plumbing for it
is simply lazy garbage. Lack of a proper layer on top of the kernel
providing infrastructure (systemd is so far from that) on desktop/server
Linux is not going to be fixed by delegating everything to the kernel
even when it massively increases attack surface.

> I would like to suggest that arch stops to disable this feature in
> future kernel versions.
>
> Resoning:
> 
> The original reason to block user namespaces were a number of security
> issues that allowed unprivileged users to access features they should
> not have access to. Due to the nature of user namespaces to provide
> isolated user environments with access to privileged features like
> other
> namespaces (inside that isolated namespace only), it should be obvious
> that this feature had to be designed carefully in order not to harm
> the
> security outside the namespace. Even though there have been issues,
> this
> feature is now considered stable enough for distros like debian and
> red
> hat to allow its use even for unprivileged users.

There's still an unrelenting torrent of security issues from it. Maybe
wait until that stops before proposing this. I don't think it's going to
stop because of how this feature is designed. It greatly increases the
attack surface and there isn't going to be a mitigating factor that
changes this situation. It's a fundamentally flawed, garbage feature and
 the arguments for it are nonsense. There are better ways to do this, by
simply not tying your hands and refusing to implement anything in user
space but instead pretending that all common features must happen in the
kernel despite major security risks and poor semantics.

> Moreover there are many applications that use this feature to provide
> or
> enhance security
> Among them are:
> 
> lxc, systemd-nspawn, docker, flatpak, bubblewrap, firejail, firefox,
> chromium

There's one well-written sandbox there (Chromium's usage) and it doesn't
require this feature. They also don't need this feature on platforms
where they have control like Android, since they can implement it in a
saner way where it doesn't massively increase kernel attack surface.

> After working with sandboxing applications for several month, it seems
> clear to me that disabling user namespaces decreases the security of
> the
> system significantly. Some of these applications can not provide core
> features due to user namespaces missing. Others have significant
> security features disabled for this reasons. But the worst part is how
> some of these projects dealt with the missing feature: Many are using
> suid bits to execute the application as root to get access to the
> features they would have inside a user namespace. And for those who
> have
> worked with suid applications and their security it will not be
> surprising that they have failed to do this securely, leading to not
> just a few local root exploits.

There's no hard requirement that they have to do it that way. They can
use a service where the user doesn't control the environment used to
spawn the application (like setuid) or full control over the environment
where it ends up being run. Application containers *really* do not need
this feature. It's far better to do it in a more secure, saner way vs.
exposing massive kernel attack surface.

> Taking firejail just as an example:
> (CVE-2017-5207)
> (CVE-2017-5206)
> (CVE-2017-5180)
> (CVE-2016-10122)
> (CVE-2016-10118)
> (CVE-2016-9016)

A junk, insecure application is not a reason to greatly reduce kernel
security for everyone.

> And that is just from the last release...
> 
> 

Re: [arch-general] Can't install AppArmor on linux-grsec kernel

[Daniel Micay]

> I installed linux-grsec kernel on my Arch system a few days back for 
> improved security. My next step is to sandbox internet-facing 
> applications such as firefox, thunderbird, torrent client, etc.
> However, 
>  it seems like grsecurity patchset doesn't have application
> sandboxing 
> capability (Does it? Couldn't find it in docs or forums).

It has an implementation of mandatory access control (grsecurity RBAC).

> In the past, I used Apparmor on Ubuntu for basic sandboxing. I tried 
> installing it on linux-grsec kernel but it seems like the necessary 
> kernel options required for installing Apparmor are disabled on 
> linux-grsec kernel. The kernel options required by Apparmor on Arch
> are [1]:

It has grsecurity RBAC and TOMOYO, but not AppArmor, SELinux or SMACK.

I won't be enabling CONFIG_AUDIT unless core/linux turns it on, and
AppArmor/SELinux depended on it when I last checked.

> I think I could enable the required options by recompiling the 
> linux-grsec kernel but it seems like the grsecurity team now provides 
> the stable patches only to commercial customers [2], so I believe I 
> won't be able to recompile the kernel myself (Perhaps I'm wrong?).

The package in the repository uses the test patch which follows along
with the most recent upstream stable release branch. The stable patches
were used in the linux-grsec-lts package which is gone. How would you be
able to install it from the repositories if it wasn't available? :\

The grsecurity stable patches are for the 3.2 and 3.14 longterm branches
and the 3.2 patches will be ending soon.

> I was hoping someone here would be able to help me install Apparmor
> on 
> linux-grsec kernel or atleast point me in the right direction. 

I recommend using RBAC or TOMOYO. If you use AppArmor, you're going to
need to recompile the kernel every week since the grsecurity patches are
very frequent (often every few days or a couple times in one day).

signature.asc
Description: This is a digitally signed message part

Re: [arch-general] ssd trim using fstrim.service and fstrim.timer

[Daniel Micay]

> 
> > Note: I could just add "discard" to /etc/fstab, but wouldn't that
> > wear out
> > the SSD faster than periodic trimming?
> 
> I don't know precise numbers, but IME none of those made a difference
> performace-wise. I'd say if SSD wear is a problem (i.e. if you
> estimate it
> within expected usage time of the device), just switch to a HDD.
> 
> HTH,

Using discard will cause less wear than using fstrim or not using TRIM
at all. TRIM gives the SSD more freedom to do wear levelling.

Anyway, wear isn't an issue on anything but low quality hardware. Even
the consumer class drives like Samsung's EVO line are going to take 5+
years to burn through the P/E cycles with extremely heavy usage. You
can keep track via the SMART data. Samsung drives have an entry with
the number of P/E cycles so far and the percentage of remaining life
and other vendors probably have a similar field (but perhaps not with
the same transparency).

signature.asc
Description: This is a digitally signed message part

Re: [arch-general] Signing kernel modules

[Daniel Micay]

On 25/07/15 03:58 PM, Damjan Georgievski wrote:
 Since some time ago, the Linux kernel has had support for
 cryptographically signed
 modules, i.e. the kernel can be configured to only load properly signed 
 modules.
 
 https://www.kernel.org/doc/Documentation/module-signing.txt
 
 
 I wouldn't go to lengths explaining the benefits of it, I was just
 wondering if Arch has the
 infrastructure to sign the modules - since developers already sign the
 kernel package itself [*],
 and in that sense we (the users) already trust them to that level.
 
 I'm not suggesting that CONFIG_MODULE_SIG_FORCE is enabled by default
 - that would break 3rd party modules, but people could optionally use
 the enforcemodulesig=1 kernel command line option if they want to.
 
 
 Thoughts?
 
 
 [*]
 though packages are gpg signed, and modules use x.509

Signed modules don't really offer any added security with a vanilla
kernel because root still has full control over the kernel via other
known mechanisms (i.e. no exploits necessary). The feature is mostly
useful for enforcing a *policy* of not allowing third party modules,
similar to the kernel taint bits which can be overwritten if you really
feel like doing it.

It might be worth enabling it for linux-grsec. Many cases can already be
handled by setting modules_disabled=1 once the needed modules are loaded.

It's not a very compelling feature though because it's only truly useful
in combination with a fully read-only root and grsecurity's
romount_protect feature.

A strong MAC policy could also plug the other attack routes... but it's
also going to prevent loading modules for that role anyway.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] current flash vulnerabilities - what to do?

[Daniel Micay]

On 16/07/15 11:30 PM, Natu wrote:
 On 07/16/2015 05:50 PM, Daniel Micay wrote:
 I don't know that I even trust openssl anymore.  I used to run chromium,
 but got tired of it passing so much information back to google, so I
 went back to firefox.  What I run is not an ideal solution.  I'm open to
 other suggestions.  I used to love chrome, but got tired of google
 spying.  And yes, you have to turn off features in firefox to avoid
 similar spying behavior, but it can be done without maintaining your own
 version of the source code.
 Chromium doesn't have 'spying' code that's not optional. It supports
 more Google services than Firefox and uses more of them out-of-the-box
 since it's the basis of the browser Google uses to promote themselves.
 Firefox is picking up support for non-Google proprietary services over
 time anyway so it'll probably end up with more in the end.
 
 Have you used something like tcpdump and verified that you can configure
 chromium such that it doesn't connect to any google servers or any other
 servers other than the ones that you've specified in the url or that are
 referenced on web pages that you've opened?  Maybe I'll have to try it
 again.  That wasn't my experience the last time I tried it.

It will check for updates to extensions... so will other browsers. You
are claiming that spying code is there yet it's an open-source project
and no one has ever found any. Prove it instead of spreading FUD.

 Mozilla gets a large amount of their funding from google, so there's
 alot of politics behind this.  Google for firefox funded by google.

Mozilla gets their money from other sources like Yahoo and the
in-browser advertising and proprietary services now.

 User security is certainly much, much lower on Firefox's priority list.
 They don't even enable ASLR yet, let alone robust sandboxing and
 advanced exploit mitigations throughout the browser. Mozilla ends up
 taking the same anti-user positions on issues like DRM after pretending
 that they're different. I can't think of one issue where they've taken
 the high road compared to Chromium. At least you know what you're
 getting with Google: profit-oriented corporation. Mozilla may not be
 accountable to shareholders, but they're even less concerned about the
 users. Google will reverse course during a PR disaster... Mozilla will
 just dig in and stonewall.

 For just one of many examples, look at the difference in the handling of
 the WebRTC IP leak:

 https://code.google.com/p/chromium/issues/detail?id=333752
 https://bugzilla.mozilla.org/show_bug.cgi?id=959893

 Oh, and the developer making the calls at Mozilla on this WebRTC privacy
 disaster developed the backdoored random number generation standard with
 the NSA. Mozilla isn't interested in commenting on this at all, as is
 usually the case (all discussion about it has been shut down).[1]
 
 I do agree that chromium is technically more advanced, but I don't
 exactly trust google either.

Yet you trust another American corporation (Mozilla) that has repeatedly
shown itself to place users and especially contributors in even lower
regard.

 I'm not really sure where to find a web
 browser that can be trusted.  I do note that both tor and jondo have
 chosen firefox, and I suspect there is a good reason for this, though
 they do apply their own modifications.  The security of TOR has been
 touted as being very solid, though I haven't seen as many reviews of
 jondo.  By default flash is disabled in both of them, but easier to turn
 on in jondofox.

The Tor browser is quite insecure. It's nearly the same thing as
Firefox, so it falls near the bottom of the list when it comes to
browser security, i.e. below even Internet Explorer, which has a basic
sandbox (but not nearly on par with Chromium, especially on Linux) and
other JIT / allocator hardening features not present at all in Firefox.
What the Tor browser *does* have that's unique are tweaks to
significantly reduce the browser's unique fingerprint.

https://blog.torproject.org/blog/isec-partners-conducts-tor-browser-hardening-study

Tor would be a fork of Chromium if they were starting again today with a
large team. They don't have the resources to switch browsers. That would
only change if they can get Google to implement most of the features
they need.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] current flash vulnerabilities - what to do?

[Daniel Micay]

On 17/07/15 01:14 PM, Jagannathan Tiruvallur Eachambadi wrote:
 We don't have it in the AUR though.

Well, I don't really think it's useful. It was just a suggestion for
people who can't tolerate Chromium downloading things like dictionaries
from Google.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] current flash vulnerabilities - what to do?

[Daniel Micay]

On 17/07/15 12:35 PM, Ralf Mardorf wrote:
 On Fri, 17 Jul 2015 11:30:05 -0400, Daniel Micay wrote:
 The Tor browser is quite insecure. It's nearly the same thing as
 Firefox, so it falls near the bottom of the list when it comes to
 browser security, i.e. below even Internet Explorer, which has a basic
 sandbox (but not nearly on par with Chromium, especially on Linux) and
 other JIT / allocator hardening features not present at all in Firefox.
 What the Tor browser *does* have that's unique are tweaks to
 significantly reduce the browser's unique fingerprint.

 https://blog.torproject.org/blog/isec-partners-conducts-tor-browser-hardening-study

 Tor would be a fork of Chromium if they were starting again today with
 a large team. They don't have the resources to switch browsers. That
 would only change if they can get Google to implement most of the
 features they need.
 
 Vivaldi is based on Chromium. How does Vivaldi compare regarding
 security and privacy to IceCat, Pale Moon, Firefox, QupZilla, Opera?
 
 https://aur4.archlinux.org/packages/?O=0K=vivaldi
 https://aur.archlinux.org/packages/?O=0K=vivaldi

It's a proprietary browser built on Chromium. It's not interesting from
a security / privacy perspective.

If you want Chromium without Google integration then you can use
Iridium. It doesn't remove any tracking / spying code though. There
wasn't any to remove. Their redefinition of tracking just means support
for any service hosted by Google (like adding a warning message when a
dictionary would be downloaded from them). Most of what it does is
changing the the default settings to be more privacy conscious.

https://git.iridiumbrowser.de/cgit.cgi/iridium-browser/log/



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] current flash vulnerabilities - what to do?

[Daniel Micay]

On 16/07/15 12:06 PM, Ralf Mardorf wrote:
 On Thu, 16 Jul 2015 13:10:33 +0100, Ben Oliver wrote:
 I have to agree with Ralf, you will be fine.

 I have been flash-free for 18 months now and it's going absolutely
 fine. Unless you have a penchant for flash games, there's very little
 reason to have it installed any more.
 
 http://www.theguardian.com/technology/2015/jul/14/facebook-end-adobe-flash-firefox-blocks-hacking

Mozilla blocked the vulnerable version, as they've done in the past. The
current release isn't blocked because there aren't yet disclosed
security vulnerabilities.

Google bundles the PPAPI Flash player with Chrome so they don't need a
comparable blacklist as it gets updated with the browser.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] current flash vulnerabilities - what to do?

[Daniel Micay]

On 16/07/15 03:48 PM, Natu wrote:
 On 07/16/2015 05:10 AM, Ben Oliver wrote:
 I have to agree with Ralf, you will be fine.

 I have been flash-free for 18 months now and it's going absolutely fine.
 Unless you have a penchant for flash games, there's very little reason to
 have it installed any more.
 
 I totally support phasing out flash, however, I run firefox inside a
 docker container and then I don't have to worry about these security
 issues since I disgard the running container and reload from the saved
 image daily.
 
 Natu

You do have to worry unless you don't care about it someone grabbing all
of your active login sessions (cookies), all of the entered form data,
etc. There's a reason for browser sandboxes being per-site-instance
instead of trying to wrap the browser as a whole. Most of the
information the attackers want is in the web browser, or can be obtained
there by grabbing passwords and other information like credit card
numbers as they're entered.

Anyway, local privilege exploits in the Linux kernel are as common as
remote Flash exploits. Docker exposes nearly the entire Linux kernel
attack surface to code in the container. It's not much of a sandbox.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] current flash vulnerabilities - what to do?

[Daniel Micay]

On 15/07/15 07:38 PM, Jens Adam wrote:
 freshplayerplugin
 
 Just to nitpick: even if it's more current (feature-wise) than
 standard Adobe Linux 11.2 flashplugin, it's still Adobe Flash and
 thus just as problematic regarding its security.
 
 --byte

PPAPI Flash runs in a strong sandbox in Chromium. However, fresh player
throws away that advantage.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] systemd new dependencies impede using OpenRC

[Daniel Micay]

While technical debate can be productive when it's not simply rehasing
the same things over and over again, simply voicing opinions is not. I
don't think it would be a good idea to develop any distribution based
upon the opinions of whoever shouts the loudest.

Decisions are made based on consensus among the people doing the work
whether they are Arch developers, trusted users or other contributors in
the community without those fancy titles. Arch isn't striving for
popularity so the popularity of the decisions among the users isn't
important. It's developed for the people doing the work.

I interpreted this thread as a bug report with 'The Arch Way' page on
the wiki so it hasn't been for naught. That page has been rewritten to
better reflect what has always been the development philosophy instead
of being a vague advertisement for the distribution with questionable
claims.

https://wiki.archlinux.org/index.php/The_Arch_Way

It's not perfect, but it's a lot more grounded in reality now.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] systemd new dependencies impede using OpenRC

[Daniel Micay]

On 01/07/15 02:36 PM, João Miguel wrote:
 First of all, thank you for such a quick reply.
 
 Now, I don't want to preach. But I will not pretend I chose Arch Linux at
 random. I chose it for many reasons, an important one of them being that
 I liked the Arch Way, it made sense to me, and it seemed you were
 following it. Now it seems to belong to a forgotten past.
 
 On Wed, Jul 01, 2015 at 10:34:01AM -0400, Daniel Micay wrote:
 Arch is as much a systemd-based distribution as it is a Pacman-based
 distribution at this point. (...)
 Is it now? https://wiki.archlinux.org/index.php/The_Arch_Way

That's an unprotected page on the wiki, not an authoritative source on
anything to do with the distribution.

Arch has always been a simple distribution in terms of the developer
perspective, not the user one. Using systemd made it simpler than ever
in that regard because much more work is taken care of by both the
systemd developers and all of the projects shipping unit files.

It has never been a minimalist distribution. Splitting packages is rare
compared to other distributions, and dependencies aren't made optional
whenever possible.

It has also never been a distribution offering much user freedom /
choice compared to Gentoo and even Debian. There are very few cases
where there are multiple packages offering different configurations of
the same project. There's no equivalent to update-alternatives or the
comparable uses of USE flags. Changing /bin/sh from Bash will be broken,
as will changing the python symlink to point to python2 instead of
python3 even though this works on some other distributions. It doesn't
strive to offer choices like this, and never has. It would mean a *lot*
more complexity on the development side of things along with major
deviations from upstream.

Arch is the *opposite* of a user-centric freedom. The opinion of users
has no weight here. Only the developers have an opinion, and there
aren't voting systems as there are in Debian. Technical decisions are
made based on merit via consensus among the developers, not popularity.


 it is not simple, not minimalist, and not user-centric.

Certainly not minimalist, but those other two claims are questionable.

Arch has *never* been minimalist... a Linux kernel with every module
available and every feature enabled at least when there's no non-bloat
related cost, feature-packed/complex GNU tools, nearly all optional
features enabled across all the packages, etc.

 However, making so many packages depend on it so that any basic desktop
 usage (in the case of the util-linux dependency, even non-graphical usage)
 does break one principle listed in the aforementioned page: freedom. In
 fact, I ought to quote it:

Arch is the opposite of a distribution with lots of user freedom. Users
will come and go based on whether they like the technical decisions made
by the developers. The popularily of those decisions has no impact on
how things are done, regardless of how vocal users are about it.

 Nonetheless, respecting the quoted principle, I could easily replace
 systemd by OpenRC when I chose to. Note that just last month, over 3
 years had passed after systemd was adopted, and I could still use
 OpenRC. Now, for whatever reason, the principle was broken without
 notice. I'd expect news or an email in this mailing list, to which I've
 been paying close attention (though I knew less than the authors about
 most problems...).

You can still use it, it's just becoming increasing more difficult at a
pretty steady pace. Those packages didn't suddenly pick up systemd
dependencies in the past few weeks / months anyway. The version control
logs disprove the claim that there are many recent changes.

 Upstreams are integrating support for systemd features and Arch is going
 to be enabling them, whether it's sd_notify support or something else.
 Upstream? Then why is it that for the same versions of the same
 packages, say, in Gentoo they are not dependencies? Example, compare
 these two:

Gentoo has USE flags so features can be optional at compile-time. Many
of the packages with dependencies on systemd in Arch link against
libsystemd, and we don't split up the package as is the norm here. If
there's a package with an *unnecessary* dependency on systemd, you can
and should file a bug. I don't think there are many that depend on it
and don't use it.

 That doesn't mean I want to compile everything. Or that you should have
 packages for, say, OpenRC. The packages in the repos are not my choice,
 I'm not asking to choose which ones should be on the official repos,
 that's what the unofficial repos and the AUR are for. It just means you
 shouldn't suppose people have these or those packages installed, but
 that instead, and as you did before, even years after systemd being
 default, you should provide whatever you want, open the doors you want,
 not closing any others. Minimalism means minimal dependencies too.


 If I wanted systemd bloat and a dash of hypocrisy

Re: [arch-general] systemd new dependencies impede using OpenRC

[Daniel Micay]

On 01/07/15 07:14 PM, Jens Adam wrote:
 Thu, 2 Jul 2015 00:43:13 +0200
 Guus Snijders gsnijd...@gmail.com:
 
 Why in the world should util-linux require systemd!? Why do all
 these packages need it when they were fine without it before?  

 The first question is a relatively simple, technical question. My
 guess is that the util-linux won't currently run without system
 installed, hence the dependancy. Arch packages are usually quite
 'clean' in that respect. It's probably possible to recompile it
 without that dependency for this specific case.
 
 A little fiddling with 'pacman -Qql util-linux' and 'ldd' reveals that
 the only tools linked to (lib)systemd are 'logger', 'lslogins' and
 'uuidd'.

So it's a hard runtime dependency for a core tool that's widely used
(logger). Making it into an optional dependency would cause runtime
crashes and it would be especially bad in this case because other
packages depend on util-linux for utilities like logger.

Splitting it out into another package would be the Debian solution, but
Arch avoids that to avoid complexity. Gentoo handles this with USE flags.

 Aside from that: Yes, some packages do have too broad dependencies
 (e.g. systemd instead of libsystemd) and it certainly didn't help
 that udev became part of systemd, but in the end the train we're on
 drove off long ago, so until systemd's successor arrives on the scene
 it's probably best to accustom yourself to it and test it until all
 the bugs and edge cases are accounted for.

The package isn't going to be split so it doesn't make much sense to
refer to libsystemd. It's considered part of the mandatory base system
and the developers aren't going to go out of the way to make it optional
by adding this kind of complexity on their end.w



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] systemd new dependencies impede using OpenRC

[Daniel Micay]

On 02/07/15 02:34 PM, Neven Sajko wrote:
 Daniel Micay dixit:
 The package isn't going to be split so it doesn't make much sense to
 refer to libsystemd.
 
 It is split:
 https://www.archlinux.org/packages/core/x86_64/libsystemd/

I know it's split into systemd, libsystemd and systemd-sysvcompat. The
split is there to break a cyclic dependency, and doesn't provide the
flexibility offered by Debian's systemd split including breaking up
libsystemd. They have it set up so you can run things like
systemd-logind without systemd as init (or installed at all).



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] systemd new dependencies impede using OpenRC

[Daniel Micay]

 Now, it would be technically possible to replace *systemd* in base with a
 generic init-system which could be provided by both *systemd* and *openrc*,
 but that would make things much more complicated and *much* more effort to
 maintain.

Packages don't have a dependency on systemd because they need an init
system. They have a dependency on systemd IPC interfaces and/or
libraries not provided by openrc. If they depend on systemd without
needing something like this, it's a (very minor) bug to report.

Supporting alternative implementations of those interfaces (like
Debian's systemd-shim) would mean a lot of extra work across the
distribution.

Arch supports one specific /bin/sh implementation, one standard C
library, one standard C++ library, one C++ exception model, one
toolchain for building the system, etc. It also tends to only support
one specific implementation of a command-line utility as the main tool
and others have to be namespaced. Packages like util-linux/coreutils
aren't split into little pieces and there's no equivalent to
update-alternatives. Sure, packages like musl, libc++, libc++abi and
busybox are in the repositories but not in a way that can actually
replace anything in the base system, it just lives alongside it without
being used by any other packages.

Arch only ever supported one init system until the transition period to
systemd where it supported two. The old initscripts adopted systemd
utilities like systemd-tmpfiles before going away anyway, and the old
scripts were still supported. It was convergence to a single supported
init system rather than two choices for the base system living alongside
each other.

Making technical decisions and then going through with them with proper
integration into other packages is the only way that things are going to
be polished. The alternative is a *lot* of extra complexity, development
effort and bugs.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] systemd new dependencies impede using OpenRC

[Daniel Micay]

 WHAT? The opinion of users has no weight here ?!?!?!

Popular opinion has no weight. Zero. Technical arguments have weight but
most of them have already been debated for ages. There's a strong
consensus among the developers (and trusted users / other people who
contribute, but that's less important) in support of the status quo.

Additionally, if by 'here' you mean arch-general... most developers
probably don't subscribe to this list at all. It's used for requesting
help and flame wars. I'm quite sure that nothing said in this thread is
going to have any impact on Arch's development. There's little else to
be said about these topics. It's just a repeat of the same things over
and over again and that's exactly why it's not on the radar in terms of
development.

 I came to Arch because th way it is built and marketed looked like a real
 community and user centric, user centric not to be as easy as pushing a
 button, but in the way that i can install, configure, and use it the way i
 want to.
 Is that real?

It's a community distribution in the sense that the developers aren't
paid employees and there's no backing corporation. You can install,
configure and use it however you want but the developers are only going
to support the use cases they care about. In the base system, there's
usually *one* supported option for that component (glibc, libstdc++,
libsupc++, coreutils/util-linux, systemd, binutils/gcc, etc.). As a
binary distribution, it *has* to make many of these decisions, and
others like choosing one init system need to be made to have a polished,
maintainable distribution.

 If Arch is becoming a personal distribution to attend the developers, so
 let it clrealy in the website, so we consider choosing a new way.
 But to realize such an affirmation is a little bit dismotivating at minimum.

It has always been a distribution built around the technical views of
the developers. Unlike many other distributions, it doesn't try to
appeal to a broad audience. That's what makes it Arch rather than say a
distribution like OpenSUSE.

There's always room for more contributors, and they'll quickly become
trusted users / developers if they're talented and get along with the
other developers. The people doing the work are the ones making the
decisions, as things usually are in open source projects.

 The real POINT here is that, ANY decision made (not only systemd) have its
 pros and cons, but when someone ask for something different or question
 that, it is wise to listen, think, and answer in an polite way.
 Recently i am seeing much rage in talks, i think i will be better, and
 constructive, to filter better the words so that we can have a kind of a
 talk.

It's not like this is a technical discussion providing anything positive
for the distribution's development. It would be a lot more constructive
for everyone to avoid wasting time like this.

The constructive thing to do is accepting that Arch isn't a meta
distribution like Gentoo. It only supports choice *above* the layer of
the base system. You don't get to replace glibc, the toolchain, the core
utilities, the init system / core services (i.e. systemd), etc. without
venturing into extremely painful unsupported territory.

There are *lots* of other distributions, and most settle on either using
systemd or not supporting it *at all*, up to the point that unit files
are stripped out of packages (as Alpine does).



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] systemd new dependencies impede using OpenRC

[Daniel Micay]

On 01/07/15 09:52 AM, jmcf...@openmailbox.org wrote:

 Why in the world should util-linux require systemd!? Why do all these
 packages need it when they were fine without it before? I wouldn't like
 to install systemd, but will if necessary. Nonetheless, I don't want it
 to replace OpenRC. What can I do? I want an updated system, but I'd very
 much prefer to have one without systemd

Arch is as much a systemd-based distribution as it is a Pacman-based
distribution at this point. The best options you have available are
switching to a distribution with official support for at least one other
init system without any of systemd installed (Gentoo, Alpine, Slackware,
[...]) or just accepting that Arch is a systemd distribution and
switching to it.

There *are* systemd-based distributions like Debian that aren't (yet)
fully dropping support for other init systems, but Arch never intended
to preserve support for other options when it switched. Debian also
splits systemd into many packages and has various stubs for running
stuff that depends on it without all of it running / installed. It
sounds like you'd be happiest using a distribution where no systemd
components are ever going to be required though, and there are plenty.

Upstreams are integrating support for systemd features and Arch is going
to be enabling them, whether it's sd_notify support or something else.
Packages aren't going to go out of the way to support a niche,
unsupported use case. It's only going to get more painful to swim
against the current as time goes on. The various dbus client
implementations will probably be switched over to using kdbus this year,
for one thing. I'm sure there will be more.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Subpixel antialiasing

[Daniel Micay]

On 28/05/15 10:22 AM, Robbie Smith wrote:
 
 Doesn't Chromium use its own font rendering system? 

 Not really. It has to do a lot of font-related work to implement the 
 web
 standards but they're using freetype2/harfbuzz like everyone else.

 I've noticed that on other OSes it has its own rendering style that 
 doesn't use subpixel
 rendering either, so it looks different but not necessarily worse.

 You're getting confused by the fact that it didn't use DirectWrite on
 Windows for quite some time. It *certainly* had subpixel rendering 
 there
 and on the other supported platforms.

 Windows has both a legacy font rendering stack and a modern one with 
 a
 different appearance and better performance. Many applications use 
 the
 old stack but people spend a lot of time in browsers so it got 
 noticed.
 
 I installed Windows in a virtual machine last week because it saves
 time rebooting when I use it so infrequently, and was surprised to
 discover that the font rendering used in Chrome's web page display
 frame was greyscale and not ClearType/subpixel like the rest of
 Windows. I don't use Windows frequently enough to comment on whether or
 not this has changed.

It's not like that for everyone else. It wasn't like that before either.
It used GDI instead of DirectWrite but that just made it look different
than modern applications. It was hardly the only application still using
GDI font rendering though.

 It looks fine on my Arch install, so its either respecting my font
 settings or the in-built rendering settings are (perhaps by
 coincidence) the same as my own preferences. I should point out 
 that I
 always turn off subpixel rendering and use greyscale antialiasing
 instead, because the colour fringes on subpixel text are annoying.

 I doubt you're able to notice color fringes with black-on-white or
 white-on-black with the lcdfilter set to lcdlight. You probably just
 didn't have it configured correctly (i.e. no lcdfilter).

 I've tried various combinations of filters and settings for my font
 rendering, and all subpixel rendered text (even on OS X) looks slightly
 off; some letters have colour fringes, some letters are a slightly
 different colour to others, and it can be quite distracting. Maybe it's
 different with font hinting set to a higher value; I always opt for
 'slight' or 'none' because I prefer the smoother shapes over the more
 pixelated look of Windows.

Using the hinting information from fonts rather than auto-hinting is
important, which means using high quality fonts. Source Code Pro /
Source Sans Pro / Source Serif Pro are likely the only really well
hinted fonts in the repositories.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Subpixel antialiasing

[Daniel Micay]

 Using the hinting information from fonts rather than auto-hinting is
 important, which means using high quality fonts. Source Code Pro /
 Source Sans Pro / Source Serif Pro are likely the only really well
 hinted fonts in the repositories.

Oh, actually ttf-liberation is pretty decent now that it's based on the
Chrome OS fonts. The popular DejaVu fonts have terrible hinting though.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Subpixel antialiasing

[Daniel Micay]

 Doesn't Chromium use its own font rendering system? 

Not really. It has to do a lot of font-related work to implement the web
standards but they're using freetype2/harfbuzz like everyone else.

 I've noticed that on other OSes it has its own rendering style that doesn't 
 use subpixel
 rendering either, so it looks different but not necessarily worse.

You're getting confused by the fact that it didn't use DirectWrite on
Windows for quite some time. It *certainly* had subpixel rendering there
and on the other supported platforms.

Windows has both a legacy font rendering stack and a modern one with a
different appearance and better performance. Many applications use the
old stack but people spend a lot of time in browsers so it got noticed.

 It looks fine on my Arch install, so its either respecting my font
 settings or the in-built rendering settings are (perhaps by
 coincidence) the same as my own preferences. I should point out that I
 always turn off subpixel rendering and use greyscale antialiasing
 instead, because the colour fringes on subpixel text are annoying.

I doubt you're able to notice color fringes with black-on-white or
white-on-black with the lcdfilter set to lcdlight. You probably just
didn't have it configured correctly (i.e. no lcdfilter).



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Why irrelevant updates?

[Daniel Micay]

On 13/05/15 01:12 AM, Vitor Eiji Justus Sakaguti wrote:
 On Wed, May 13, 2015 at 12:51 AM, Eli Schwartz eschwart...@gmail.com wrote:
 It is what it is. FWIW -- I don't think they are expected, base is a
 guideline and other packages should not be making assumptions (and usually
 don't).

 I think it could reasonably be expected that one has things like
 bash/sed/tar installed, but anything likely to be manually removed from
 base I expect to be listed in package dependencies.
 
 Actually, the wiki says that the base group is always assumed to be
 installed [1] and many packages will not explicitly depend on anything
 that is in the base group even though it does depend on it in reality.
 Some bug reports about package dependencies are closed because the
 dependency is in the base group [2].
 
 [1] https://wiki.archlinux.org/index.php/Makepkg
 [2] https://bugs.archlinux.org/task/34024

The base and base-devel groups are installed in the containers used for
building, so it's quite sane to assume they're present as build deps.

The current situation is that the runtime dependencies on base (but not
base-devel) are often implicit. The wiki is only documenting the status
quo which is that removing base packages can cause breakage and there's
nothing more official than the current state of official packages. The
wiki page itself isn't an authoritative source though. It says whatever
the last person to edit it wanted it to say.

The base group itself would need cyclic dependencies to accurately
describe things. For example, some standard C functions need to spawn a
shell so glibc and bash have a dependency cycle in practice. Someone
might want to start with just filesystem and glibc in a minimal
container, but that's not really going to work. There's no perfect solution.

I think it makes more sense to add some more explicit dependencies as
needed to make minimal containers easier and call it a day.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Why irrelevant updates?

[Daniel Micay]

On 13/05/15 02:52 AM, Doug Newgard wrote:
 On Wed, 13 May 2015 02:27:14 -0400
 Daniel Micay danielmi...@gmail.com wrote:
 
 The base and base-devel groups are installed in the containers used for
 building, so it's quite sane to assume they're present as build deps.
 
 That hasn't been true for a while now. Build roots, by default, only include
 base-devel.

Oh right. Packages can't really get away with implicit deps on base in
many cases then. It'll break if they try to link against a library or if
they actually have a check() function running a test suite. I think it
can be considered a bug if running the program in check() doesn't work.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Why irrelevant updates?

[Daniel Micay]

On 13/05/15 03:15 AM, Daniel Micay wrote:
 On 13/05/15 02:52 AM, Doug Newgard wrote:
 On Wed, 13 May 2015 02:27:14 -0400
 Daniel Micay danielmi...@gmail.com wrote:

 The base and base-devel groups are installed in the containers used for
 building, so it's quite sane to assume they're present as build deps.

 That hasn't been true for a while now. Build roots, by default, only include
 base-devel.
 
 Oh right. Packages can't really get away with implicit deps on base in
 many cases then. It'll break if they try to link against a library or if
 they actually have a check() function running a test suite. I think it
 can be considered a bug if running the program in check() doesn't work.

The unsaid rule is really packages can have implicit runtime
dependencies on packages that are in both the base and base-devel groups.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] gcc bug ?

[Daniel Micay]

On 30/03/15 10:54 PM, 施不二 wrote:
 I' ve tried downgrade gcc, gcc-libs to version 4.9.2, but a new error
 occurred:
 
 /usr/include/boost/python/proxy.hpp:94:36: internal compiler error:
 Segmentation fault
  inline void proxyPolicies::del() const
 
 Is this another bug of boost?

An ICE (internal compiler error) is *always* a compiler bug. The fix may
be reporting an error, but it's still a compiler bug.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Can't reboot or shutdown my computer (cgroup: option or name mismatch)

[Daniel Micay]

On 17/03/15 09:13 AM, Janilson Andrade wrote:
 Hi all.
 After months trying many things and after posting in arch forum[1] I am here 
 asking if anyone could help me.Everytime I try to reboot or shutdown my 
 computer, after turning everything off, my system hangs and display one of 
 these messages below.
 a) cgroup : option or name mismatch, new: 0x0, old: 0x4 systemd
 shutdown[1]: Failed to finalize  file systems, ignoring
 
 b) A stop job is running for Daemon for power management (20s/1min 30s)I use 
 Gnome 3, when I've changed to my DE to KDE the reboot options worked 
 sometimes, but most of the times it didn't. After it stop working at all I've 
 come back to Gnome, since I can't reboot my system no matter what I do.
 OBS: I know the cgroup message is just a warning to most of people, but for 
 me it freezes my system and I can only turn the power off and on in order to 
 reboot my computer,
 I really want some help of how can I at least search for the possible things 
 that is causing this problem.Sorry for long e-mail.
 
 [1] System doesn't reboot/shutdown (cgroup : option or name mismatch) / 
 System Administration / Arch Linux Forums

The fact that it's the last message printed out before it stalls does
not imply it is the cause. AFAIK this warning occurs *everywhere* so I
doubt it has anything to do with your issue.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Severity of Failed checksum for PKGBUILD

[Daniel Micay]

On 19/02/15 11:39 PM, Mark Lee wrote:
 On 02/19/2015 05:46 PM, Mark Lee wrote:
 On 02/19/2015 05:24 PM, Lukas Jirkovsky wrote:
 On 19 February 2015 at 21:42, Doug Newgard scim...@archlinux.info wrote:
 You can't. If upstream provides a checksum, that gives you some 
 verification,
 but since github doesn't, there's no way to verify any of it.

 I don't know about github, but with bitbucket the checksums of these
 generated tarballs may change occasionally as I had this issue with
 luxrender. However, the sources were always the same, it was the
 metadata that changed.


 How important are checksums to PKGBUILDS then? Should sources with
 varying checksums just have 'SKIP' in their integrity arrays?

 Regards,
 Mark

 
 Furthermore, if the integrity check is different from upstream, is a
 packager obligated to host a copy of the source code for GPLed software?
 
 Regards,
 Mark

No... the integrity check not matching is not because an out-of-tree
source tree was used. The checksums are certainly not there to improve
security, that's what GPG signatures are for.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Severity of Failed checksum for PKGBUILD

[Daniel Micay]

On 20/02/15 09:03 AM, Mark Lee wrote:

 The checksums are there for integrity. The GPG signatures only confirm
 the packager built the package. My question is if a packager's
 PKGBUILD fails a checksum and the license is GPL, how does the
 packager fullfill their requirement to provide the source code? How
 does the packager prove that the source was used to build the
 binaries, especially when there are hash collisions in md5? The
 packager seems to offset the source code necessities by grabbing the
 source from upstream, but the checksums don't match...

The checksums don't prove anything. A package could have simply been
built with --nocheck, it may have been built with a corrupt source (it
does nothing for the initial and most important download) or upstream
may have swapped out the tarball as they often do.

Complying with the GPL may mean making source packages available... but
the checksums really have nothing to do with it. You cannot possibly
reconstruct the sources from a checksum if the upstream download goes
away... it has no relevance to the GPL.

 I understand that the metadata changed which changed the checksum, but
 that doesn't really change the question of what to do with source code
 versioning systems that have changing checksums and the need to supply
 source code for GPL projects.

Checksums aren't sources. Checksums aren't a proof that the package was
built from those sources. Checksums also aren't a valuable security
mechanism, unlike the support for GPG verification of sources. They're
blindly updated on every release and clobbering release is common... so
we've all learned to ignore checksum failures. I don't understand what
this has to do with the GPL.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Severity of Failed checksum for PKGBUILD

[Daniel Micay]

On 20/02/15 09:03 AM, Mark Lee wrote:
 
 No... the integrity check not matching is not because an
 out-of-tree source tree was used. The checksums are certainly not
 there to improve security, that's what GPG signatures are for.
 
 
 The checksums are there for integrity. The GPG signatures only confirm
 the packager built the package. My question is if a packager's
 PKGBUILD fails a checksum and the license is GPL, how does the
 packager fullfill their requirement to provide the source code? How
 does the packager prove that the source was used to build the
 binaries, especially when there are hash collisions in md5? The
 packager seems to offset the source code necessities by grabbing the
 source from upstream, but the checksums don't match...
 
 I understand that the metadata changed which changed the checksum, but
 that doesn't really change the question of what to do with source code
 versioning systems that have changing checksums and the need to supply
 source code for GPL projects.
 
 Regards,
 Mark

This is Arch's way of complying with the GPL:

https://sources.archlinux.org/

It should really be generated by devtools instead of on the server,
sure, but either way it proves nothing. The packager can trivially
build the package with different sources... if you don't trust us, then
you have bigger problems and nothing short of examining the compiled
code is going to prove anything. This is why people care about
deterministic, reproducible builds:

https://wiki.debian.org/ReproducibleBuilds

It makes it possibly to audit binary builds sanely.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Severity of Failed checksum for PKGBUILD

[Daniel Micay]

On 20/02/15 09:41 AM, Florian Pelz wrote:
 Hi,
 
 On 02/20/2015 03:22 PM, Daniel Micay wrote:
 On 20/02/15 09:03 AM, Mark Lee wrote:
 I understand that the metadata changed which changed the checksum, but
 that doesn't really change the question of what to do with source code
 versioning systems that have changing checksums and the need to supply
 source code for GPL projects.

 Checksums aren't sources. Checksums aren't a proof that the package was
 built from those sources. Checksums also aren't a valuable security
 mechanism, unlike the support for GPG verification of sources. They're
 blindly updated on every release and clobbering release is common... so
 we've all learned to ignore checksum failures. I don't understand what
 this has to do with the GPL.

 
 Checksums proof that the sources you downloaded when running makepkg are
 the same sources the author of the PKGBUILD used. This can be a valuable
 security measure when those sources are not downloaded on a secure
 connection (http instead of https and the like).

The checksums can only verify that you obtained the same sources as the
author of the PKGBUILD. Since upstreams clobber the old tarballs so
often, failure to validate doesn't mean much...

The vast majority of users make use of the binary packages and the
checksums do absolutely nothing to secure the main attack vector which
is a compromise of the sources downloaded by the packager. It is only
relevant to the tiny minority of people building a package with ABS.

The more meaningful compromise needs to happen to the actual package in
the repositories. A compromise of the server hosting the sources is the
most likely way for this to happen. HTTPS can't do anything to defend
against it. HTTPS can only defend against a MITM attack on a specific
downstream packager.

There is support for validating sources with GPG signatures, which is a
complete solution to this issue. If you care, then file issues for any
packages that aren't using the upstream signatures yet, and complain to
upstream if they aren't signing the releases.

 I'm not sure if downloads over the git:// protocol are actually
 verified, because the transfer is definitely not secure. I do hope so.

Git's read-only protocol is not authenticated. It supports SSH and HTTPS
which do have two different forms of authentication, both of which are
very flawed. Signed tags make a lot more sense, and you shouldn't be
using code from development branches if you care a lot about robustness
and security, since



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Severity of Failed checksum for PKGBUILD

[Daniel Micay]

On 20/02/15 10:04 AM, Martti Kühne wrote:
 On Fri, Feb 20, 2015 at 3:53 PM, Mark Lee m...@markelee.com wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Checksums aren't sources, they are a method of verifying the integrity
 of sources. In other words, while different files can have the same
 md5sum (hash collision), a failed checksum indicates something has
 definitely changed in the package. Checksums can have false positives
 but not false negatives.

 In other words, the provided source is definitely not the same as the
 source the packager used (metadata difference in this case). If
 checksums are as useless as you claim, why even offer them if they
 cannot be reproduced for certain packages?

 Do packagers really just ignore checksums and blindly update on
 every release?

 Regards,
 Mark
 
 
 I get your point.
 Consider though, that Archlinux' comparably slim manpower cannot
 account for every time upstream does things to their source tarballs,
 usually in an unannounced manner. The concept is here, that ABS users
 need to figure out themselves whether *their* sources are retrafficked
 dns or the packager's. In so far as these things happen, they don't
 even have to do with archlinux that much (it's not very nice of an
 upstream to do that), so try not to bark up the wrong tree.
 
 Cheers!
 mar77i

You should really just tell upstream to sign their releases, because it
wipes out the attack vector instead of just making it possible to audit
whether a MITM attack on the original. packager occurred like hashes.

The hashes provide no security for the initial packaging work and no
defense against an attack that's done by compromising the upstream
sources, which is far more realistic than a targeted MITM attack on a
specific Arch Linux packager.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Severity of Failed checksum for PKGBUILD

[Daniel Micay]

On 20/02/15 10:22 AM, Florian Pelz wrote:
 On 02/20/2015 03:59 PM, Daniel Micay wrote:
 The vast majority of users make use of the binary packages and the 
 checksums do absolutely nothing to secure the main attack vector
 which is a compromise of the sources downloaded by the packager. It
 is only relevant to the tiny minority of people building a package
 with ABS.

 The more meaningful compromise needs to happen to the actual
 package in the repositories. A compromise of the server hosting the
 sources is the most likely way for this to happen. HTTPS can't do
 anything to defend against it. HTTPS can only defend against a MITM
 attack on a specific downstream packager.

 
 The difference is that if certain government organizations infiltrate
 the Arch servers or upstream, they break everyone's security. They may
 be less likely to do that compared to breaking just yours.

Compromising the Arch servers doesn't provide the ability to produce
valid signed packages, and compromising the upstream servers doesn't
provide the ability to produce valid signed sources. You would need to
compromise the machine used by the developer and gain access to their
private key and whatever else you're after. There's little that can be
done once that is accomplished...

 There is support for validating sources with GPG signatures, which
 is a complete solution to this issue. If you care, then file issues
 for any packages that aren't using the upstream signatures yet, and
 complain to upstream if they aren't signing the releases.

 
 This certainly is the right way to go, but I don't think enough
 upstream projects care to make it a viable option for personal
 computers today. PKGBUILD checksums provide less security, but they do
 provide some.

Lots of our packages already use them, and that's only a fraction of the
ones that could be using them. Just look at how long the rebuild list
for pacman 4.2's improved signing was or look at the Arch package source
tree yourself.

PKGBUILD checksums provide *zero*, yes *zero* security for the case that
matters most, which is the build done by the packager. It does provide
the ability for other people to verify that a MITM attack was not used
to target a specific packager... but that is far, far less likely than a
compromise of the sources on the upstream server and it can't do
anything about that.

Providing an audit trail is distinct from providing security, and there
is more than one way to do that. Signed source tarballs would tackle the
same thing while avoiding the problem of upstream clobbering the sources
or the sources simply becoming unavailable. Many upstreams don't
continue hosting sources for older versions...

Clobbering the sources is common enough that a validation failure is
only a bit suspicious and likely isn't even going to be investigated.
That is the reality of the hashes - they are near useless.

 On 20/02/15 09:41 AM, Florian Pelz wrote:
 I'm not sure if downloads over the git:// protocol are actually 
 verified, because the transfer is definitely not secure. I do
 hope so.

 Git's read-only protocol is not authenticated. It supports SSH and
 HTTPS which do have two different forms of authentication, both of
 which are very flawed. Signed tags make a lot more sense, and you
 shouldn't be using code from development branches if you care a lot
 about robustness and security, since

 
 It is not authenticated, but I care about checksums. (Authentication
 would be even better because it ensures others don't know what
 software I am running -- but that is too much to ask.) I don't see why
 SSH and HTTPS are flawed, other than a distrust in certificate
 authorities.

It can also only protect against a MITM attack against upstream and
downstream, which as I already pointed out is not as likely as
compromising the sources on the upstream server - and it can't do
anything about that.

Trust in certificate authorities is trust in many corporations and
governments around the world. It's trust in tends of thousands of
individuals with the ability to sign whatever they want. An attacker
with the ability to perform a targeted MITM attack on a specific Arch
developer likely has the ability to sign whatever they want.

Compromising the upstream sources in a subtle way when they upload the
next release will be nearly impossible to detect - only the upstream
developer who uploaded the source tarball

Git's SSH protocol implies having SSH access to at least a Git shell on
the server and isn't ever used for read access in practice. SSH has a
simple, sane whitelist-based model based on a public key / IP pair. It
will warn whenever the server IP changes which is not at all uncommon
and means that nearly every developer has learned to ignore it.

 I still hope that git:// downloads use checksums. I'm not sure.

They can do it if they're fetching a specific version...



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Severity of Failed checksum for PKGBUILD

[Daniel Micay]

On 20/02/15 09:53 AM, Mark Lee wrote:
 On 02/20/2015 09:22 AM, Daniel Micay wrote:
 On 20/02/15 09:03 AM, Mark Lee wrote:

 The checksums are there for integrity. The GPG signatures only
 confirm the packager built the package. My question is if a
 packager's PKGBUILD fails a checksum and the license is GPL, how
 does the packager fullfill their requirement to provide the
 source code? How does the packager prove that the source was used
 to build the binaries, especially when there are hash collisions
 in md5? The packager seems to offset the source code necessities
 by grabbing the source from upstream, but the checksums don't
 match...
 
 The checksums don't prove anything. A package could have simply
 been built with --nocheck, it may have been built with a corrupt
 source (it does nothing for the initial and most important
 download) or upstream may have swapped out the tarball as they
 often do.
 
 Complying with the GPL may mean making source packages available...
 but the checksums really have nothing to do with it. You cannot
 possibly reconstruct the sources from a checksum if the upstream
 download goes away... it has no relevance to the GPL.
 
 I understand that the metadata changed which changed the
 checksum, but that doesn't really change the question of what to
 do with source code versioning systems that have changing
 checksums and the need to supply source code for GPL projects.
 
 Checksums aren't sources. Checksums aren't a proof that the package
 was built from those sources. Checksums also aren't a valuable
 security mechanism, unlike the support for GPG verification of
 sources. They're blindly updated on every release and clobbering
 release is common... so we've all learned to ignore checksum
 failures. I don't understand what this has to do with the GPL.
 
 Checksums aren't sources, they are a method of verifying the integrity
 of sources. In other words, while different files can have the same
 md5sum (hash collision), a failed checksum indicates something has
 definitely changed in the package. Checksums can have false positives
 but not false negatives.

I'm well aware of what cryptographic hashes are. A failed validation of
the sources indicates that the sources are different from what the
packager specified in the PKGBUILD, which could mean that the download
was corrupt or that something malevolent happened but in all likelihood
it simply means that upstream clobbered the tarball.

 In other words, the provided source is definitely not the same as the
 source the packager used (metadata difference in this case). If
 checksums are as useless as you claim, why even offer them if they
 cannot be reproduced for certain packages?

Again, checksums prove nothing. If the packager wants to build the
binary package with different sources, they can do that without the
checksums in the PKGBUILD reflecting it. The packager can ask makepkg
not to verify the checksums, and they could simply modify makepkg to
remove the check if there was no switch to turn it off... it in no way
avoids placing trust in the packager.

 Do packagers really just ignore checksums and blindly update on
 every release?

Yes, what else do you expect them to do? They run `updpkgsums` which
downloads the sources and updates the checksums... it has no security
value for the packages in the repositories. Zero. Value.

If upstream cares about security, they sign their releases. There is
fantastic support for verifying GPG signatures in makepkg, and we use it
whenever it's available. File a bug if a package could be using it and
is not using it.

Either way, you trust the packagers of binary packages. It is difficult
to verify that trust... the only way it is easy to do is if the build is
deterministic and the version of the packages used to build it is
specified. Since Arch's toolchain is rolling, reproducing builds is
going to be quite hard...



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Severity of Failed checksum for PKGBUILD

[Daniel Micay]

On 20/02/15 10:26 AM, Mark Lee wrote:

 However, the issue still stands regarding checksums. Perhaps packages
 with metadata changes should just not include checksums? Or, they could
 just link to the sources.archlinux.org in those cases with checksums.

Ideally, devtools would generate a source package, sign it and upload it
along with the binary packages. It would eliminate the minor flaws in
the current GPL compliance and there would actually be a way to obtain
the original sources used to build the package and compare to whatever
upstream currently offers.

The source packages are currently generated by a cron job on the
server... I'm sure patches are welcome but you aren't going to find many
people who really care.

 In addition, I was thinking more along the lines of coercion.

I don't know what you mean. The checksums prove absolutely nothing about
how the binary package was built. The packager can provide whatever
checksums they want, regardless of what sources they used to build the
package.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Severity of Failed checksum for PKGBUILD

[Daniel Micay]

On 20/02/15 12:54 PM, Florian Pelz wrote:
 On 02/20/2015 04:51 PM, Daniel Micay wrote:
 PKGBUILD checksums provide *zero*, yes *zero* security for the case
 that matters most, which is the build done by the packager. It does
 provide the ability for other people to verify that a MITM attack
 was not used to target a specific packager... but that is far, far
 less likely than a compromise of the sources on the upstream server
 and it can't do anything about that.

 
 I guess the likelihood depends on who the attacker and what their
 motive is, but you are probably right. Still, checksums improve
 security in cases that can matter if there is no better verification
 from upstream.
 
 That said, if the security is verified another way, is there no need
 to use SHA256 rather than MD5, because the latter should be enough for
 ensuring there are no download errors?

Security is provided by signatures. The hashes don't provide security
for the official packages, only an audit trail at best and only for
detecting a MITM attack, not an upstream compromise. The hashes are also
redundant in an --allsource package.

 Trust in certificate authorities is trust in many corporations and 
 governments around the world. It's trust in tends of thousands of 
 individuals with the ability to sign whatever they want. An
 attacker with the ability to perform a targeted MITM attack on a
 specific Arch developer likely has the ability to sign whatever
 they want.

 
 Any certificate authority caught signing fraudulent certificates would
 no longer be trusted. They surely can, but they would not want to.
 Unless you are an extremely high value target, I think CAs can be trusted.

So why are Comodo and TurkTrust still trusted, among others?

Anyway, they can get away with quite a lot before getting caught - if
they ever are. I'm not sure why you would be worried about an extremely
niche targeted attack on Arch Linux but not this.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] pacman security when importing new keys?

[Daniel Micay]

On 10/02/15 08:15 AM, Mike Cloaked wrote:
 On Tue, Feb 10, 2015 at 12:59 PM, Dennis Lange den...@lumalab.net wrote:
 
 Hi Manuel,

 thanks for posting this thread. I also wondered about the key from
 eworm. Sure he is a trusted user but accepting keys made me a little bit
 nervous. Is there a way to verify my pacman keys?

 Dennis


 I guess you can verify fingerprints from the list at
 
  https://www.archlinux.org/master-keys/

No, you don't have to anything like that. There is never a need to
manually verify the keys of developers and trusted users because they
are part of the web of trust model. There are 5 trusted master keys and
they are part of the installation from the get go. A key is trusted if
it is signed by at least 3 master keys - you only ever need to mark keys
for third party repositories as trusted.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] pacman security when importing new keys?

[Daniel Micay]

On 10/02/15 07:59 AM, Dennis Lange wrote:
 Hi Manuel,
 
 thanks for posting this thread. I also wondered about the key from
 eworm. Sure he is a trusted user but accepting keys made me a little bit
 nervous. Is there a way to verify my pacman keys?
 
 Dennis

It already verifies the keys by default... you have to go out of your
way to manually mark a key as trusted. Importing a key != marking a key
as trusted. It is only trusted if 3+ of the five master keys signed it
or if you explicitly mark it with pacman-key.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Hello!

[Daniel Micay]

Is it really necessary to fill our inboxes with this spam?



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] gpg source validation for kernel.org style signatures

[Daniel Micay]

On 04/01/15 05:03 PM, Doug Newgard wrote:
 On Sun, 4 Jan 2015 22:05:21 +0100
 Christian Hesse l...@eworm.de wrote:
 
 Hello everybody,

 pacman 4.2.0 gained support for verifying source tarballs with
 kernel.org style signature. Some (even essential) packages could
 benefit from that, linux and git come to mind.

 How to handle this? Report a bug for every package? Provide a list
 here?
 
 A lot of it is already happening:
 https://www.archlinux.org/todo/validpgpkeys-integrity-check/
 
 If you want it added to a package that isn't on that list, the bug
 tracker is probably the best bet. Note that the linux package already
 has it.
 
 Doug

That rebuild is just to fix packages that were already using GPG
signatures and need the fingerprint(s) added. There are a lot that could
be using them and aren't yet. This could likely be automated to a large
extent.

Using a script to detect if HTTPS works for fetching the sources along
with checking for signature files by appending .asc and .sig seems like
a promising plan.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] gpg source validation for kernel.org style signatures

[Daniel Micay]

On 04/01/15 04:05 PM, Christian Hesse wrote:
 Hello everybody,
 
 pacman 4.2.0 gained support for verifying source tarballs with kernel.org
 style signature. Some (even essential) packages could benefit from that,
 linux and git come to mind.
 
 How to handle this? Report a bug for every package? Provide a list here?

I would create a wiki page with the list and then see if you can find a
developer interested in mass-adding the missing signatures. I'd be
interested in helping with it for [community], but you'll likely be able
to do it yourself soon ;).

Note that you should check svn rather than abs because theres usually no
rebuild for something like this. The linux{-lts,-grsec} packages are
using the new feature now.

I expect that this can be automated to a large extent. Looking for files
with .asc / .sig extensions doesn't need to be done by hand. It also
makes sense to figure out which packages can use HTTPS to fetch sources
since that's a lot better than nothing if no signatures are available.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] gpg source validation for kernel.org style signatures

[Daniel Micay]

 I do not think we need HTTPS, though it does not hurt. If anybody tries to
 fool us with man-in-the-middle via HTTP we should detect that just fine with
 broken signatures (given signatures are provided...).

Well, I mean when no signatures are available. It's not really that
common for upstream to sign the packages :(. HTTPS is pretty common
though, especially considering all of the projects hosted on sites like
github.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] gpg source validation for kernel.org style signatures

[Daniel Micay]

On 05/01/15 12:28 PM, Leonid Isaev wrote:
 On Mon, Jan 05, 2015 at 10:16:10AM +0100, Christian Hesse wrote:
 I do not think we need HTTPS, though it does not hurt. If anybody tries to
 fool us with man-in-the-middle via HTTP we should detect that just fine with
 broken signatures (given signatures are provided...).

 Appending .sign may help as well. In fact for an example file archive.tar.xz
 we may want to check for {${FILE},${FILE%.(xz|bz2|gz)}}.{asc,sig,sign}

 $ export FILE=archive.tar.xz
 $ echo {${FILE},${FILE%.(xz|bz2|gz)}}.{asc,sig,sign}
 archive.tar.xz.asc
 archive.tar.xz.sig
 archive.tar.xz.sign
 archive.tar.asc
 archive.tar.sig
 archive.tar.sign
 
 Does makepkg(8) know how to check sigs of .tar files as opposed to .tar.xz?

Yes, it learned how to do that in the most recent release.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Standard group for hardware user?

[Daniel Micay]

On 05/01/15 02:24 PM, Neale Pickett wrote:
 I apologize for mentioning systemd.
 
 What non-deprecated group would be best for a hardware user?

Who is telling you that the groups in base are deprecated?



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Standard group for hardware user?

[Daniel Micay]

On 05/01/15 02:30 PM, Neale Pickett wrote:
 https://wiki.archlinux.org/index.php/users_and_groups#Deprecated_or_unused_groups

The groups have been replaced / deprecated as a way of giving hardware
access to users with local sessions. That doesn't mean that they're
deprecated as a whole or that they'll go away. It's possible, but you
can't determine that from opinions on a wiki.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] depends vs. optdepends

[Daniel Micay]

Arch currently uses optional dependencies even when it means that
executables provided by the package aren't going to work with the
minimal set of dependencies. The packages could be split up more to
avoid this without pulling in more stuff, but it's not what packagers
usually choose to it. It's a design choice left up to the packager, not
a bug.

The namcap tool reports missing libraries when packages are built with
devtools so you're not going to be finding stuff that hasn't already
been reported automatically.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] [arch-gen] does using tmp-rng enables tpm at all?

[Daniel Micay]

On 24/12/14 02:45 PM, Javier Vasquez wrote:
 Hi,
 
 Seems like on i5 and i7 chips the way to get random numbers through HW
 is to use tpm-rng (intel-rng is no longer available for them).  An by
 reading [1] seems like a pretty good idea.
 
 However I have no intention to use tpm at all, neither I want any
 possibility to get any one monitoring my machine, which is one of the
 possible use cases with tpm.
 
 Does one, just by using tpm to feed entropy, open any door on linux
 for any other tpm functionality?  Or is it totally safe to use
 tpm-rng?
 
 Thanks,

Ivy Bridge and later have an RDRAND instruction exposing a hardware
random number generator so there's no need for any TPM stuff. RDSEED
will be provided by Broadwell and later for lower-level access to the
hardware entropy rather than via a CSPRNG. It's already leveraged by the
kernel and libraries like the C++ random implementation in libstdc++.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Official releases from upstream

[Daniel Micay]

On 23/11/14 04:35 AM, Ralf Mardorf wrote:
 Hi,
 
 while for virtualbox Arch Linux does follow upstream, even while there
 is a critical known USB issue, for Claws Mail, where AFAIK isn't a
 critical issue, it doesn't follow upstream.
 
 On Sun, 23 Nov 2014 09:07:22 +
 nore...@thewildbeast.co.uk wrote:
 The latest release is v. 3.11.1, what can you observe with that?
 
 Stable release   3.11.1 (October 27, 2014; 23 days ago) -
 https://en.wikipedia.org/wiki/Claws_Mail
 
 Latest Release: 3.11.1 (News), on 27 October 2014 -
 http://www.claws-mail.org/news.php
 
 $ pacman -Si claws-mail | grep Ver
 Version: 3.11.0-2
 
 ;)
 
 I try to understand this, but I can't understand it. Is there latitude
 for the maintainers to decide what is an official release from upstream
 and what isn't?
 
 Regards,
 Ralf
 
 PS:
 The Claws package isn't a problem for me.
 $ pacman -Q claws-mail-git
 claws-mail-git 3.11.1.r26.g00cade7-1
 But the virtualbox package is really an annoyance.

Packages are updated when the maintainers have time to do it.

This crappy trolling isn't helping your case.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Netflix in Arch?

[Daniel Micay]

On 10/10/14 11:52 AM, David Rosenstrauch wrote:
 I noticed the announcement today that Ubuntu now supports Netflix
 streaming, due to new features recently added to the Chrome browser.
 
 https://insights.ubuntu.com/2014/10/10/watch-netflix-in-ubuntu-today/
 
 Does this work on Arch's version of Chrome as well?  Are additional
 package installations required?
 
 Thanks,
 
 DR

It should work out-of-the-box in Chrome, but Chromium doesn't come with
the PPAPI plugin for EME. I don't know how feasible it is to get that
plugin working in Chromium. For the Pepper Flash plugin, it's as simple
as dropping the shared object into the directory and adding 2 cli flags.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Zombie Processes

[Daniel Micay]

On 26/08/14 07:54 PM, Mark Lee wrote:
 To all,
 
 I was wondering regarding the killing of a zombie process. As far as I
 know, a zombied process is inherited by root when it's parent is
 killed. The kernel periodically calls wait() which reaps the zombie
 process and frees its memory. I was wondering if a possible attack
 could be mounted by the zombie process when it is inherited by root.
 
 Regards,
 Mark

Orphaned processes are inherited by init (pid 1). A modern init like
systemd uses an event loop and handles the signals (SIGCHLD) in a
non-blocking fashion. Linux also provides the ability to turn other
processes into sub-reapers, and has a concept of process namespaces
where the first process in the namespace is treated as init for those
processes. I don't think this is a viable attack surface.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Vim clipboard option

[Daniel Micay]

On 21/08/14 07:59 AM, lolilolicon wrote:
 On Thu, Aug 21, 2014 at 1:39 PM, Yamakaky yamak...@yamaworld.fr 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 of your terminal emulator. :r!xsel may also be useful.
 

 Thanks

If you already have X and a terminal emulator installed, why bother
avoiding the gvim package?



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Vim clipboard option

[Daniel Micay]

On 21/08/14 04:43 AM, Manolo Martínez wrote:
 On 08/21/14 at 07:39am, Yamakaky wrote:
 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.
 
 I too find this disappointing. The only reason I have gvim installed is
 in order to use the + and * registers.
 
 Manolo

The vim package only exists to avoid some dependencies. If it linked
against X libraries, there wouldn't be much point in having it.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] [arch-dev-public] linux 3.16 in [testing]

[Daniel Micay]

On 13/08/14 12:44 PM, Thomas Bächler wrote:
 Am 13.08.2014 um 17:29 schrieb Damjan Georgievski:
 On 13 August 2014 17:26, Damjan Georgievski gdam...@gmail.com wrote:
 yey
 thanks for CONFIG_USER_NS=y

 ahh no, I'm stupid.
 Checked it on another machine and got excited before hand
 :/

 anyway. is there a reason this is not enabled now?
 all the mainstream distros hae it enabled now Fedora, RHEL/CentOS 7,
 Ubuntu and Debian (at least on the backported kernel)
 
 I'd think about it, if the feature wasn't entirely useless. Despite the
 lack of official documentation, I found a document that described how it
 worked. After reading that document I concluded that the feature is a
 huge potential security risk with no actual benefit.
 
 If you give me a valid use case for USER_NS, I might reconsider, but
 every use case I can imagine is crushed by the limitations of the
 implementation.

The use case is primarily allowing unprivileged containers, by making it
possible to unshare namespaces, enter a chroot and do some mount
operations as a regular user. The systemd user session provides the
other half of the picture, which is using control groups as an
unprivileged user.

The secondary purpose is the quirky uid / gid mapping but I don't really
understand the intended use case. It seems way too obscure to ever have
it exposed in container implementations and you would need root to do
anything interesting with it.

It's completely broken from a security POV so enabling it without
reverting the patch allowing unprivileged user namespaces isn't sane.

The latest vulnerability was disclosed only yesterday:

http://www.openwall.com/lists/oss-security/2014/08/12/6

The key patch for Fedora's kernel:

http://pkgs.fedoraproject.org/cgit/kernel.git/tree/Revert-userns-Allow-unprivileged-users-to-create-use.patch

The same -EPERM return for unprivileged users is also a non-optional
part of the grsecurity patch set. AFAICT, it also prevents the class of
mounts used in the latest CVE. I might just be misunderstanding how user
namespaces are supposed to work.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] [arch-dev-public] linux 3.16 in [testing]

[Daniel Micay]

On 13/08/14 01:40 PM, Damjan Georgievski wrote:
 anyway. is there a reason this is not enabled now?
 all the mainstream distros hae it enabled now Fedora, RHEL/CentOS 7,
 Ubuntu and Debian (at least on the backported kernel)

 I'd think about it, if the feature wasn't entirely useless. Despite the
 lack of official documentation, I found a document that described how it
 worked. After reading that document I concluded that the feature is a
 huge potential security risk with no actual benefit.
 
 What security risk exactly? There was one that I know of, and it was fixed.

A dozen local root exploits based on unprivileged user namespaces have
been disclosed. Fedora and grsecurity patch in a check to prevent
unprivileged use of user namespaces. You can find many with a search
like 'CVE user namespace linux'. The latest vulnerability is only a day
old...

 If you give me a valid use case for USER_NS, I might reconsider, but
 every use case I can imagine is crushed by the limitations of the
 implementation.
 
 The use case is that you don't need root access to start a container.
 I can run Firefox with a limited view to the filesystem for example,
 as a normal user.
 Or limited view to the network, for ex. just ipv4, just ipv6, just vpn.

It's not possible to sandbox an X11 application externally, so Firefox
isn't a good example. The ability to see the contents of every window,
draw arbitrary stuff in the windows, capture every input event without
focus, etc. completely breaks it.

The AppArmor profiles in distributions like Ubuntu for graphical
applications are security theater. There's a reason for the Chromium
renderer sandbox proxying all rendering requests over a pipe. Even an
OpenGL context is too much before dri3, and it's only *theoretically*
possible for dri3 drivers to be secure in that context.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] [arch-dev-public] linux 3.16 in [testing]

[Daniel Micay]

On 13/08/14 01:21 PM, Mihamina Rakotomandimby wrote:
 On 08/13/2014 08:09 PM, Leonid Isaev wrote:
 As you know, user_ns is a necesary prerequisite for unpriviileged
 containers:
 https://www.stgraber.org/2014/01/17/lxc-1-0-unprivileged-containers/ 
 . AFAIU,
 currently only Ubuntu 14.04 supports those.

 However, I agree with you that CONFIG_USER_NS is better left disabled
 in -ARCH
 kernels. After all, people using containers should be able to compile
 a custom
 kernel...
 
 Hi all,
 
 One use case of using LXC might be to want to quicky have a virtual
 environment running.
 
 Easing the work by defaulting to a ready-to-work kernel would be nice.
 
 Regards.

Containers work fine without CONFIG_USER_NS. You just can't spawn them
without being a privileged user. There's a good reason for that, as
shown by the endless stream of local root exploits via user namespaces.

Having uid 0 or root equivalent capabilities in a container with or
without user namespaces is equivalent to root access on the host due to
flaws in the implementation. By removing the check for a privileged
user, upstream just guaranteed that sane distributions are not going to
enable the feature (at least without patching it, which isn't Arch's style).



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Ncurses over ssh

[Daniel Micay]

On 26/07/14 04:09 PM, luc.li...@mailoo.org wrote:
 Hello everyone.
 
 I am using newsbeuter to handle my rss feeds, and, to be able to use it
 from all my computers, I set it up on a server with ssh enabled. When I
 log in this server with ssh, then launch newsbeuter, everything works
 fine. But when I invoke it that way : `ssh [ip] newsbeuter`, newsbeuter
 fails with 'Error opening terminal : unknown'.
 
 When I explicitly export $TERM[1], newsbeuter is able to launch, but it
 doesn't detect the terminal size and can't handle keys.
 
 So I'll be glad if you know how to fix that matter.
 Thanks in advance.
 
 
 In a totally unrelated matter, do you know how to make a remote program
 launch local scripts through ssh ?
 
 [1] : The command used is : 
   `ssh [ip] 'export TERM=rxvt-unicode-256color  newsbeuter'`
 

You need the terminal's terminfo on the server. If you don't have root
access there you can put it in your home directory.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] [vte3] Wrong permissions for /etc/profile.d/vte.sh ?

[Daniel Micay]

On 22/07/14 09:55 AM, Neitsab wrote:
 Hi,
 
 As I was checking some stuff about environment variables, I noticed that
 I have one file in /etc/profile.d which doesn't have the same perms as
 the others:
 
 $ ls -la /etc/profile.d/
 total 72
 drwxr-xr-x  2 root root 4096 19 juil. 20:36 .
 drwxr-xr-x 91 root root 4096 22 juil. 15:04 ..
 -rwxr-xr-x  1 root root  102 24 oct.   2013 gpm.sh
 -rwxr-xr-x  1 root root 2154 21 mars  02:16 infinality-settings.sh
 -rwxr-xr-x  1 root root 1972  7 janv.  2014 infinality-settings.sh.old
 -rwxr-xr-x  1 root root  140 28 mars  15:29 jre.csh
 -rwxr-xr-x  1 root root  152 28 mars  15:29 jre.sh
 -rwxr-xr-x  1 root root  156 15 mars  22:09 libreoffice-common.csh
 -rwxr-xr-x  1 root root  156 15 mars  22:09 libreoffice-common.sh
 -rwxr-xr-x  1 root root 1052  4 juil. 14:44 locale.sh
 -rwxr-xr-x  1 root root   50  1 juil. 11:55 mozilla-common.csh
 -rwxr-xr-x  1 root root   50  1 juil. 11:55 mozilla-common.sh
 -rwxr-xr-x  1 root root  699 19 juin  21:08 perlbin.csh
 -rwxr-xr-x  1 root root  668 19 juin  21:08 perlbin.sh
 -rwxr-xr-x  1 root root  115 13 mai   23:37 seahorse-ssh-askpass.sh
 -rwxr-xr-x  1 root root   36 20 janv.  2014 vdpau_vaapi.sh
 -rw-r--r--  1 root root 1881 23 juin  22:05 vte.sh
 -rwxr-xr-x  1 root root  115 11 juin   2013 x11-ssh-askpass.sh
 
 $ pacman -Qo /etc/profile.d/vte.sh
 /etc/profile.d/vte.sh belongs to vte3 0.36.3-1
 
 I verified it wasn't some bad commands on my side which changed this
 file's perms by reinstalling it together with vte-common, however the
 file remains 644.
 
 Does anybody have any hints about why this file, which is a .sh script,
 doesn't have execute permissions like the others in /etc/profile.d
 folder? I didn't find any change in latest PKGBUILDs which would cause
 such permissions, so should I suppose it is an upstream decision?
 
 Regards

The permissions don't really matter because they're sourced as long as
they're readable.

It's incorrect for upstream to be doing this though, because their
script needs to be run for every interactive shell. I already filed a
bug about it:

https://bugs.archlinux.org/task/39684

Arch needs to provide a separate directory sourced in non-login shells
and put this there instead.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] yaourt - tmpfs error: No space left on device

[Daniel Micay]

On 18/07/14 03:40 PM, Csányi Pál wrote:
 Hi,
 
 I'm trying to install icecat with yaourt but get always error: No
 space left on device.
 
 $ df -H
 Filesystem  Size  Used Avail Use% Mounted on
 /dev/sda366G   38G   26G  60% /
 tmpfs   3.2G 0  3.2G   0% /dev/shm
 tmpfs   3.2G 0  3.2G   0% /sys/fs/cgroup
 tmpfs   3.2G  3.2G  160k 100% /tmp
 tmpfs   627M  4.1k  627M   1% /run/user/1000
 
 I have installed my arch linux on one partition only, on /dev/sda3.
 
 I tried to install icecat several times, moreover after a reboot too,
 but always get this error message.
 
 I tried also to setup yaourt and makepkg:
 /etc/yaourtrc
 TMPDIR=/tmp
 
 /etc/makepkg.conf
 BUILDDIR=/tmp/makepkg
 
 Still get the above error.
 What can I do to solve this problem?

Stop building a very large package in a filesystem of very limited size.
The BUILDDIR option is unset by default, and if you leave it unset
`makepkg` will work fine.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] yaourt - tmpfs error: No space left on device

[Daniel Micay]

On 18/07/14 03:49 PM, Csányi Pál wrote:
 2014-07-18 21:44 GMT+02:00 Daniel Micay danielmi...@gmail.com:
 On 18/07/14 03:40 PM, Csányi Pál wrote:
 
 I'm trying to install icecat with yaourt but get always error: No
 space left on device.

 $ df -H
 Filesystem  Size  Used Avail Use% Mounted on
 /dev/sda366G   38G   26G  60% /
 tmpfs   3.2G 0  3.2G   0% /dev/shm
 tmpfs   3.2G 0  3.2G   0% /sys/fs/cgroup
 tmpfs   3.2G  3.2G  160k 100% /tmp
 tmpfs   627M  4.1k  627M   1% /run/user/1000

 I have installed my arch linux on one partition only, on /dev/sda3.

 I tried to install icecat several times, moreover after a reboot too,
 but always get this error message.

 I tried also to setup yaourt and makepkg:
 /etc/yaourtrc
 TMPDIR=/tmp

 /etc/makepkg.conf
 BUILDDIR=/tmp/makepkg

 Still get the above error.
 What can I do to solve this problem?

 Stop building a very large package in a filesystem of very limited size.
 The BUILDDIR option is unset by default, and if you leave it unset
 `makepkg` will work fine.
 
 Before I edited the file: /etc/makepkg.conf
 
 I tried to install with yaourt the icecat package but get the same
 error message.
 That is way I edited the /etc/makepkg.conf file and set the BUILDDIR option 
 to:
 BUILDDIR=/tmp/makepkg
 
 So, leaving it unset doesn't work here.

Leave it unset and build with makepkg directly.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] yaourt - tmpfs error: No space left on device

[Daniel Micay]

On 18/07/14 03:51 PM, Travis Thompson wrote:
 Set BUILDDIR=/var/tmp instead, /tmp is filling up.

Or just use the *default* of not building in a global directory...
especially /tmp which is a ramdisk.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] gparted cant take root priviliges

[Daniel Micay]

On 10/07/14 06:56 PM, Klearchos-Angelos Gkountras wrote:
 In my new laptop , I install archlinux and works fine but also when I
 try to use gparted not promont one dialog to have root priviliges ..
 how to fix that ?

I'm a bit unsure about what you're asking for. To avoid the error, you
should run it with root privileges with a command like `pkexec gparted`.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Why doesn't the evolution package version follow the stable release version from upstream?

[Daniel Micay]

On 25/06/14 04:42 PM, Ralf Mardorf wrote:
 Why is the Evolution package in extra evolution 3.12.3-1,
 https://www.archlinux.org/packages/extra/x86_64/evolution/ , when the
 current stable version from upstream still is 3.12.2?
 
 On Wed, 2014-06-25 at 20:07 +0100, at evolution-l...@gnome.org Patrick
 O'Callaghan wrote:
 the latest stable release currently being 3.12.2
 
 The latest stable release tarballs were uploaded on May 12, 2014:
 
 evolution-3.12.2.tar.xz (NEWS)
 evolution-data-server-3.12.2.tar.xz (NEWS) -
 https://wiki.gnome.org/Apps/Evolution#Get_the_Source_Code

The wiki page wasn't updated for the latest stable release:

https://download.gnome.org/sources/evolution/3.12/

The tags in the Git repositories are the best source of information, not
the wiki documentation.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] inetutils and the 'base' group

[Daniel Micay]

On 16/06/14 07:35 PM, Leonid Isaev wrote:
 Hi,
 
   Is there a reason why core/inetutils is in base group, i.e. which
 packages implicitly rely on it? It was added to base around Aug. 2011 ago, I
 think because of hostname(1), but shouldn't this functionality be now provided
 by hostnamectl?
 
 Thanks,

It's likely just in base because it was viewed as convenient. You can
temporarily change the hostname with `sysctl kernel.hostname=foo` alone
anyway.

AFAIK it's a bug if there's an implicit dependency on base, although
it's not clear if an implicit make dependency on base is allowed as it
is for base-devel. It would be nice if that was spelled out clearly
instead of left up to community documentation on the wiki.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] makepkg.conf CFLAGS

[Daniel Micay]

On 02/06/14 06:58 AM, Martti Kühne wrote:
 On Sun, Jun 1, 2014 at 2:03 PM, Yamakaky yamak...@yamaworld.fr wrote:
 Hi

 I just discovered the gcc option march=native. It enables all the
 local-supported optimizations, without downsides except the non-portability
 of the binaries. Is there a reason why it isn't enabled by default, as cross
 platform compilation isn't used by most of the users (I think) ?

 Yamakaky
 
 
 Cross platform compilation is a requirement for the most important of
 makepkg's users, namely our package maintainers...
 
 cheers!
 mar77i

The official packages are built in a clean container with the makepkg
configuration files in the devtools package. In the past, portability
issue would have been a factor. I do think the status quo of having it
match the devtools flags is perfectly fine, as it's trivial to replace
`-march=x86_64 -mtune=generic` with `-march=native`.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] makepkg.conf CFLAGS

[Daniel Micay]

On 02/06/14 07:24 AM, Martti Kühne wrote:
 On Mon, Jun 2, 2014 at 1:11 PM, Daniel Micay danielmi...@gmail.com wrote:

 The official packages are built in a clean container with the makepkg
 configuration files in the devtools package. In the past, portability
 issue would have been a factor. I do think the status quo of having it
 match the devtools flags is perfectly fine, as it's trivial to replace
 `-march=x86_64 -mtune=generic` with `-march=native`.
 
 That's pretty cool, actually. Thanks for the update. Meanwhile you
 didn't make clear why don't you side with OP after justifying his
 point?
 
 cheers!
 mar77i

Generating efficient code for the local machine by default makes sense
and doesn't get in the way of building truly portable packages with
devtools. However, I'm sure there are users who build packages without
devtools and then expect it to be portable and changing the default is
bound to lead to noise on the bug tracker.

Arch is primarily a binary distribution, and anyone rebuilding some set
of packages with ABS to eek out a bit of extra performance is aware that
the default compiler flags need to be changed. It's not going to make a
difference for 99% of Arch users, and for *most* (but not all) packages
the performance gain is negligible.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] GNU IceCat should be in the official repos

[Daniel Micay]

Firefox and IceCat already implement an API for DRM called NPAPI. It
provides DRM via Flash and even Silverlight with Pipelight.

Firefox won't be implementing DRM. It will be providing yet another API
for a third party blob to latch onto to provide DRM via HTML directly.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] systemd-journald taking too much memory

[Daniel Micay]

On 19/05/14 04:53 AM, Ondřej Kučera wrote:
 Hello,
 
 from time to time, Thunderbird crashes on my computer. It doesn't happen
 all that often and so far I haven't lost any data, so this actually
 doesn't bother me that much.
 
 But, when it happens, suddenly the process systemd-journald starts
 allocating more and more memory (this last time it went up to 1.3 GB),
 which makes the computer start swapping and for a few minutes it becomes
 quite unusable. I have no idea what journald is trying to log at that
 moment. This is what I found in the journal afterwards (also notice that
 last lines are out of order):
 
 May 19 10:24:18 rory systemd-journal[7906]: Permanent journal is using
 28.0M (max allowed 15.0M, trying to leave 4.0G free of 131.5G available
 → current limit 28.0M).
 May 19 10:24:19 rory systemd[1]: Starting Journal Service...
 May 19 10:24:19 rory systemd[1]: systemd-journald.service stop-sigterm
 timed out. Killing.
 May 19 10:24:19 rory systemd[1]: Starting Journal Service...
 May 19 10:24:19 rory systemd[1]: systemd-journald.service: main process
 exited, code=killed, status=9/KILL
 May 19 10:24:19 rory systemd[1]: Unit systemd-journald.service entered
 failed state.
 May 19 10:24:19 rory systemd[1]: systemd-journald.service has no holdoff
 time, scheduling restart.
 May 19 10:24:19 rory systemd[1]: Stopping Journal Service...
 May 19 10:24:19 rory systemd[1]: Starting Journal Service...
 May 19 10:24:19 rory systemd[1]: Started Journal Service.
 May 19 10:24:19 rory systemd-journal[7906]: Journal started
 May 19 10:22:31 rory systemd[1]: systemd-journald.service watchdog timeout!
 May 19 10:24:05 rory systemd[1]: Starting Trigger Flushing of Journal to
 Persistent Storage...
 May 19 10:24:08 rory systemd[1]: Started Trigger Flushing of Journal to
 Persistent Storage.
 
 Is there a journald setting I could use to prevent this huge memory
 allocation?
 
 Ondřej

It's from logging the core dump:

https://wiki.archlinux.org/index.php/Systemd#Disabling_application_crash_dumps_journaling



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Why is it dangerous to run makepkg as root?

[Daniel Micay]

On 17/05/14 03:12 PM, Bardur Arantsson wrote:
 On 2014-05-17 14:40, Roland Tapken wrote:
 Hi,

 I'm using arch for about half a year on a few systems, but every time I 
 install something from aur I'm asking myself one question:

 Why is it considered dangerous to run makepkg as root?

 My first guess was that the PKGBUILD usually comes from an untrusted source 
 and 
 may contain code to attack my system (copy personal data or install a 
 rootkit 
 or something like that). But on the other hand, this file tells makepkg how 
 to 
 build the package that will be installed as root, so if the author of the 
 PKGBUILD has bad purposes he will just put that code into the created 
 package.

 
 Maybe I've missed something reading through this thread, but *assuming*
 (yeah, I know) that packages can't run arbitrary scripts at install time
 (which I think is a valid assumption for pacman), there is a slight
 theoretical advantage to the current behavior in that if you never run
 $NEW_PACKAGE *as root* then your system cannot be compromised quite as
 extensively as if you had run PKGBUILD as root (which would allow
 completely arbitrary commands as root, either through a malicious
 PKGBUILD or other attack channels such as an exploitable gcc, etc.).

Packages can and do run arbitrary code via the install script. This is
used to do everything from adding new users / groups to regenerating
caches / databases.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] How to disable systemd-tmpfiles-clean.timer

[Daniel Micay]

On 09/05/14 02:02 AM, Mark Lee wrote:
 On 05/09/2014 01:41 AM, Daniel Micay wrote:
 On 09/05/14 01:29 AM, Mark Lee wrote:

 To Daniel,

 I'm pointing out that respect for people shouldn't affect technical
 skepticism. People can rant against whomever they want as long as it has
 technical criticism (at least on this mailing list). 
 
 Accusing the developers of bad faith and spreading misinformation about
 the project is not technical skepticism. I'll quote one of my earlier
 statements:
 
 Bashing an open-source project and spreading FUD about it is always an
 attack on the open-source community, whether it's GNOME, systemd, KDE,
 PHP, or something else. It's one thing to take a rational look at a
 project and criticize it, and quite another to promote content
 accusing the developers of having bad faith without *any* evidence.
 
 Hence, don't make anything personal.

 Regards,
 Mark
 
 You're implying that I've made it personal, but I don't think I've done
 any such thing. What have I said that you think is venturing into the
 land of a personal attack?
 
 
 To Daniel,
 
 Regarding, your personal attack. I inferred a personal attack when you
 claimed that the Arch developers were also SystemD developers and were
 well respected. It seemed to me like you were peer pressuring the fellow
 into withdrawing the issue by belittling his credentials in comparison
 to a community and powerful developers. This looked like a David vs.
 Goliath situation to me; we shouldn't ever be forcing Archers with
 questions in this situation. The opinion of a user should be just as
 valuable as the opinion of a developer.

Calling the systemd developers chauvanistic and claiming they have bad
faith is a personal attack. There was no issue raised by the person I'm
replying to, only flaming and a link to more flamebait containing actual
personal attacks and outright lies.

They claimed attacking systemd was not attacking the Arch community, and
I clearly quoted that part of their message and responded to it by
stating that since prominent members of the community (including
developers) are systemd developers, attacking the systemd developers
*is* attacking the Arch developers.

I get the impression that you only skimmed over the conversation or read
the last few messages, because you seem to be missing the context.

 There are right ways to handle things and wrong ways. The Archer  had a
 technical issue and an opinion. Solving the technical issue is more
 important. We can usually just ignore the opinion. This may seem
 hypocritical that I'm typing this (since this doesn't solve the issue
 for the Archer), so it'll be the last response I make regarding a
 person's opinionated response (at least on this thread).
 
 With that in mind, I hope the issue's solved for the Archer.
 
 Regards,
 Mark

The person I responded to is not the one asking a technical question.

Here is the first message they sent to the list:

https://mailman.archlinux.org/pipermail/arch-general/2014-May/036206.html

It's not the original post with the technical issue. It's someone taking
the time to link to FUD (ad hominem attacks on the systemd developers,
hollow rhetoric and misinformation) because there was a post about
systemd. Have you read the content of the link?



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] How to disable systemd-tmpfiles-clean.timer

[Daniel Micay]

On 08/05/14 11:44 AM, LANGLOIS Olivier PIS -EXT wrote:
 -Original Message-
 From: arch-general [mailto:arch-general-boun...@archlinux.org] On Behalf
 Of Lukas Jirkovsky
 Sent: Thursday, May 08, 2014 3:54 AM

 Please don't start another systemd flamewar. And BTW, automatic /tmp
 cleaning was there since the beginning.
 
 I agree to not start a flamewar but hopefully systemd devs do not consider 
 their SW as perfect and are looking to improve it by taking into 
 consideration the userbase complains about it.
 
 Maybe automatic /tmp cleaning was there since the beginning but it appears 
 that it never worked on my systems until very recently after using ArchLinux 
 for over 2 years.

Several of the Arch developers are systemd developers, so it's not like
you're talking about a group of outsiders here. The /tmp cleaning
doesn't delete recently touched files (10 days), so perhaps you've never
noticed it before.

 -Original Message-
 From: arch-general [mailto:arch-general-boun...@archlinux.org] On Behalf
 Of Paul Gideon Dann
 Sent: Thursday, May 08, 2014 5:26 AM

 On Thursday 08 May 2014 09:53:41 Lukas Jirkovsky wrote:
 On Thu, May 8, 2014 at 9:46 AM, Christos Nouskas n...@archlinux.us
 wrote:
 On 8 May 2014 09:43, Olivier Langlois oliv...@olivierlanglois.net wrote:
 Since a recent update (I have first noticed a couple of weeks ago
 this new systemd enhancement), systemd started to automatically
 clean /tmp directory daily. This is not something that I like as I
 prefer to decide when to clean up and to manually perform the clean
 up.

 The /tmp directory is intended for temporary files, after all. If you need 
 them
 to stick around, I'd recommend using /var/tmp. But yeah, masking the unit
 file should solve this for you, I think.
 
 I was forecasting that this comment would come when I wrote the original 
 request. While I agree with what you say, I think that it is reasonable to 
 let the user have the control over when it is cleaned. Without denaturing the 
 /tmp folder, I'm using it to experiment patches on some packages or launch 
 computation and store results into /tmp to return back at them the next 
 morning. I have been a bit shocked to find out one morning that my files have 
 been deleted by my system. IMHO, this goes against the rule of least surprise 
 which is a pillar of the unix philosophy.

Use your home directory. /tmp is a dangerous place since it's a shared,
world-writable ephemeral directory. The only things that are stored
there are temporary files used by currently open applications. In most
cases, $XDG_RUNTIME_DIR is a better choice (sockets, fifos, etc.).

 I understand that for some sysadmins it might be convenient to have an 
 automatic cleanup but IMHO they should explicitly set it up. I am not too 
 sure that this is a good default behavior.

It's good default behaviour, as long as you aren't abusing /tmp for
stuff it's not meant for.

 That being said, I'll try to mask the service. Thank you very much for your 
 replies.

You can override the /usr/lib/tmpfiles.d/tmp.conf file in
/etc/tmpfiles.d and get rid of the cleaning.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] How to disable systemd-tmpfiles-clean.timer

[Daniel Micay]

On 08/05/14 03:46 AM, Christos Nouskas wrote:
 On 8 May 2014 09:43, Olivier Langlois oliv...@olivierlanglois.net wrote:
 Since a recent update (I have first noticed a couple of weeks ago this
 new systemd enhancement), systemd started to automatically clean /tmp
 directory daily. This is not something that I like as I prefer to decide
 when to clean up and to manually perform the clean up.
 
 I'm sorry I don't have a solution to your problem (which is also mine
 as I tend to keep a lot of files in /tmp...) but the invasiveness of
 systemd is just outrageous and, allow me to say, not KISS at all, i.e.
 do one thing and do it well [0]. First it was udev, next dbus, then
 journal logs, then timers, now automatic /tmp cleaning. What's next,
 mandatory reboot on each update?

The Arch developers decided to use it for timer units and logs, not
anyone else. It's still the same udev it always was, and dbus is moving
into the kernel, not systemd (systemd interacts with it as a client and
provides a compatibility layer for yet to be updated processes).

I guess you'll be upset that Tom (one of the Arch developers) wrote
systemd-networkd. You'll probably also be upset that there's going to be
a simple systemd-console from the kmscon developer (who is an Arch user)
and a systemd-timesyncd for basic NTP clients not needing a full blown
server with complicated RTC handling.

Everyone else will continue on with their lives, because they realize
that there's nothing wrong with maintaining more than one binary/library
under one version control repository.

 This is not a rant against Arch or its devs and community, but against
 systemd; the sad facts speak for themselves.

This is a rant against the Arch devs and the Arch community. Several of
the developers and several people involved with the community are
systemd developers, and there is certainly consensus among the Arch
developers and trusted users to use systemd.

 [0] http://boycottsystemd.org/

There are no facts there. I already responded to this FUD on reddit:
http://www.reddit.com/r/archlinux/comments/24zj10/what_are_the_benefits_of_partitioning_disk_space/chcao5u



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] How to disable systemd-tmpfiles-clean.timer

[Daniel Micay]

On 08/05/14 05:01 PM, Nowaker wrote:
 This is not a rant against Arch or its devs and community, but against
 systemd; the sad facts speak for themselves.
 
 This is a rant against the Arch devs and the Arch community. Several of
 the developers and several people involved with the community are
 systemd developers, and there is certainly consensus among the Arch
 developers and trusted users to use systemd.
 
 This sounds really bad. Ranting against systemd should never be taken as
 ranting against Arch in general or some specific Arch developers. After
 all, Arch Linux is a Linux distribution, not a systemd distribution. ;)
 Systemd was chosen for some important reasons, I support this decision,
 but it shouldn't be considered a holy grail. The holy grail is pacman,
 and anyone who rants against pacman rants against Arch devs and
 community! ;-)

Some of the Arch developers are pacman developers, and others are
systemd developers. Both projects are part of the base install and are a
significant part of the distributions flavour. The msys2 project uses
pacman on Windows, so it's not really any more specific to Arch than
systemd.

Bashing an open-source project and spreading FUD about it is always an
attack on the open-source community, whether it's GNOME, systemd, KDE,
PHP, or something else. It's one thing to take a rational look at a
project and criticize it, and quite another to promote content accusing
the developers of having bad faith without *any* evidence.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] How to disable systemd-tmpfiles-clean.timer

[Daniel Micay]

On 08/05/14 05:10 PM, Christos Nouskas wrote:
 I guess you'll be upset that Tom (one of the Arch developers) wrote
 systemd-networkd.
 
 You guess wrong.

So you're okay with it providing networking, but not timer units? Timer
units were a very simple addition on top of the existing event loop,
while networkd is a significant project.

 You'll probably also be upset that there's going to be
 a simple systemd-console from the kmscon developer (who is an Arch user)
 and a systemd-timesyncd for basic NTP clients not needing a full blown
 server with complicated RTC handling.
 
 Again wrong. Unless they're enabled by default.

The systemd console would replace the virtual terminals provided by the
kernel. The NTP client might make sense as something enabled by default,
although I don't know if it's planned to be.

 Everyone else will continue on with their lives, because they realize
 that there's nothing wrong with maintaining more than one binary/library
 under one version control repository.
 
 Don't escalate and don't make it personal. You're just guessing wrong;
 I don't mind running systemd, unless it decides what's best for me
 without asking me. Clearing /tmp is one of those annoying things.

I'm don't see how I'm making it personal with a bit of sarcasm.

You already made it quite personal by promoting FUD with gems like this:

 systemd's team is noticeably chauvinistic

Do you think Tom and Dave are chauvanistic? Or did you not really read
what you linked to?

 I've also been annoyed by the fact that I have a PC that won't boot
 with systemd198-2, because systemd can't mount /usr/local (which is
 empty).

I'm not sure what you mean by this.

 On the other hand I do love the _netdev  x-systemd.automount
 directives in /etc/fstab.
 
 This is a rant against the Arch devs and the Arch community.
 
 Wrong yet again. It isn't. I didn't say The Arch and systemd devs are
 this and that, I just pointed out some facts about *systemd* that I
 find annoying and this has nothing to do with the developers
 themselves, for crying out loud! Are you suggesting people should just
 shut up and never voice an unfavourable opinion? Or you'd rather
 prefer a court of flatterers praising how perfect this world is?

No, I'm asking you to stop spreading misinformation and attacks on the
developers behind the project (who also develop Arch Linux). If you
interrupt a constructive thread with FUD, you can expect to be called out.

 Several of
 the developers and several people involved with the community are
 systemd developers, and there is certainly consensus among the Arch
 developers and trusted users to use systemd.
 
 Which makes systemd perfect how exactly?

No one said it's perfect.

 Anyway, if I've offended anyone I offer them my apologies.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] How to disable systemd-tmpfiles-clean.timer

[Daniel Micay]

On 08/05/14 05:37 PM, Christos Nouskas wrote:
 Do accept the fact that not everyone is content with everything
 systemd and just leave it at that. Thank you and bye.

That can be expressed without calling the developers chauvanistic and
spreading misinformation. It's yet a free software project available to
people who want it, and you can choose to use an alternative like runit
instead.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] How to disable systemd-tmpfiles-clean.timer

[Daniel Micay]

On 08/05/14 03:40 PM, Daniel Micay wrote:

 [0] http://boycottsystemd.org/
 
 There are no facts there. I already responded to this FUD on reddit:
 http://www.reddit.com/r/archlinux/comments/24zj10/what_are_the_benefits_of_partitioning_disk_space/chcao5u
 

Whoops, wrong link:

http://www.reddit.com/r/programming/comments/23tyez/this_group_wants_to_revive_the_systemd_debate/ch0maow



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] How to disable systemd-tmpfiles-clean.timer

[Daniel Micay]

On 09/05/14 01:01 AM, Mark Lee wrote:
 
 To all,
 
 Don't make any of this personal. In addition, I hope the inclusion of
 systemd in Arch Linux has more justification than just some Arch
 developers are also Systemd developers. Arch may not be a democracy, but
 it's not supposed to be infested with cronyism either (I don't think it
 is). Let's all be calm and collected here and sort things out.
 
 Regards,
 Mark

I never stated that it was a reason for it being included in Arch Linux.

You're misrepresenting what I said.

The context of the thread is someone promoting content including a lot
of inaccurate claims and ad hominem attacks like this: systemd's team
is noticeably chauvinistic and anti-Unix and yet making this claim:

 This is not a rant against Arch or its devs and community, but against
 systemd; the sad facts speak for themselves.

I was countering the claim by pointing out that the group of people they
are disparaging includes several Arch developers and other prominent
people in the community.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] How to disable systemd-tmpfiles-clean.timer

[Daniel Micay]

On 09/05/14 01:29 AM, Mark Lee wrote:
 
 To Daniel,
 
 I'm pointing out that respect for people shouldn't affect technical
 skepticism. People can rant against whomever they want as long as it has
 technical criticism (at least on this mailing list). 

Accusing the developers of bad faith and spreading misinformation about
the project is not technical skepticism. I'll quote one of my earlier
statements:

 Bashing an open-source project and spreading FUD about it is always an
 attack on the open-source community, whether it's GNOME, systemd, KDE,
 PHP, or something else. It's one thing to take a rational look at a
 project and criticize it, and quite another to promote content
 accusing the developers of having bad faith without *any* evidence.

 Hence, don't make anything personal.

 Regards,
 Mark

You're implying that I've made it personal, but I don't think I've done
any such thing. What have I said that you think is venturing into the
land of a personal attack?



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Comment on: Use systemd timers instead of /etc/cron.{hourly, daily, weekly, monthly}?

[Daniel Micay]

On 06/05/14 04:13 PM, Leonid Isaev wrote:

 After re-reading the documentation I have to take this back, systemd timers
 seem to implement all features provided by cronie.

AFAIK, the only notable missing feature is the ability for non-root
users to run jobs when they're not logged in. This is intentionally left
out, and it's not hard for an administrator to replicate the feature
with a timer unit for a specific user allowed to run jobs.

(of course, this isn't really the topic at hand :P)



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Installing Archlinux alongside Ubuntu on aWindows8 UEFI laptop

[Daniel Micay]

 Can I safely treat this Manjaro as an Arch installation?   I did this with
 Antergos a couple of years ao, and it worked out fine.  Will I run into a
 roadblock down the road?

Antergos is Arch Linux, Manjaro isn't.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Comment on: Use systemd timers instead of /etc/cron.{hourly, daily, weekly, monthly}?

[Daniel Micay]

On 05/05/14 09:05 AM, Maciej Puzio wrote:
 I have been testing the issue for a week. Daily timers are fired
 between 0:00 and 0:01 without exception - all timers at the same time,
 all machines at the same time, every day at the same time. The largest
 variation I have seen was 30 seconds. So yes, there is definitely an
 issue with AccuracySec=12h not being honored.
 
 However, whether timer accuracy is 30 seconds or 12 hours, this makes
 little difference to me, as both are unacceptable without the
 possibility to customize timer elapse time. I have reverted all my
 Arch machines to previous cron-based config and intend to keep it this
 way. Perhaps it is not cool, but at least it works.
 
 Which brings me to what I consider the most important problem here.
 Having read the original thread on arch-dev-public I was left with an
 impression that perceived coolness of the new setup took precedence
 over consideration of its impact. As a result, modification has been
 released without sufficient testing, as we can clearly see now. It did
 not help that discussion was carried on a mailing list that does not
 allow user comments. Perhaps a larger audience would have allowed a
 consideration of alternative solutions. An example of such a solution
 would be hourly/daily/monthly/weekly timers that execute scripts from
 relevant /etc/cron.* directories. That would allow for removal of
 cronie while sidestepping timer elapse problems that we are discussing
 here. It would also have a benefit of handling all cron tasks in
 addition to logrotate/updatedb/man-db/shadow.
 
 Thanks
 Maciej Puzio

cronie was not enabled by default before and these systemd timers are,
so there has been an improvement in the default configuration.

The issue of systemd not spreading out the timers enough can be fixed,
because if true it's a bug.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Installing Archlinux alongside Ubuntu on a Windows 8 UEFI laptop

[Daniel Micay]

On 01/05/14 05:07 PM, Alan E. Davis wrote:
 This is insanity...   The first time I have encountered the much maligned
 Micro$oft UEFI / Secure Boot adventure.  On my new Thinkpad Yoga, with a
 Wacom active digitizer and pen.
 
 Ubuntu was a walk in the park.  I installed Ubuntu naively, alongside the
 new Windows 8.1 laptop.  It took maybe an hour to break my resolve to take
 my time.  It was a disconcerting experience.  I now have a system that
 boots Ubuntu 2014.04, through a convoluted process of signing into Windoze,
 then  backing out through advanced settings to boot from a Menu.   If I
 were trying to lock in my customer base, I couldn't have designed it any
 better, or made it any more uncomfortable, myself.  Ubuntu picks up the
 Wacom pen, and almost everything else.  But it's not Archlinux.
 
 I am a bit fearful, but decided that Archlinux, which I am using on two
 other machines, would potentially be the better choice.
 
 I have two more partitions, one of a /home and another for an Arch /boot,
 so I went ahead and walked through the most of the install, except for
 installing the boot manager.
 
 I am stuck now.  I don't want to compromise what I have already gained.
 Now I need to learn how to set up the system to boot any of the three OSs.
 
 I am puzzled by the variety of approaches I have seen; hence, I am reaching
 out here on the mailing list.
 
 I saw advice to use GRUB but install it in the boot PARTITION.  Not sure
 how to do this, and not sure whether it will work.
 
 
 Does this make sense to anyone?
 
 Alan
 

You shouldn't have a separate boot partition. Install gummiboot or
refind to the existing FAT32 ESP partition and mount that as your /boot.
It's *easier* than dealing with MBR/BIOS because you can do it entirely
via EFI/Boot/BOOTX64 rather than messing with EFI entries.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Installing Archlinux alongside Ubuntu on a Windows 8 UEFI laptop

[Daniel Micay]

On 01/05/14 06:02 PM, Alan E. Davis wrote:
 This looks interesting, and I am tempted to walk into the deep water.  It
 raises some questions.
 
 Will gummiboot or refind also find the Ubuntu partition?

You should use the ESP (EFI system partition) to store all of the
kernels. The loader (gummiboot) will find the Windows loader along with
any kernels on that partition. You really aren't going to want separate
boot partitions.

 The original partition structure of the machine there were four or five
 partitions, and another one popped up in the higher end of the disk.   I
 stumbled into the install, with the Ubuntu installer, and ended up with
 four linux partitions in addition to the Windoze partitions.  At some point
 I used gparted to resize, and this might have been the step that botched
 the structure.  But in any event, I have three Linux partitions of 50G
 each, and a swap partition.  Ubuntu is sitting in one of those partitions.
 
 I have no idea what is an EFI partition.  I have seen instructions,
 presumably for those who are wiping the Windows and starting from scratch,
 to make an EFI partition.
 
 I finally realized why there are so many partitions, and learned to use
 gdisk when walking through the Archlinux install.
 
 Here is a some information from the gdisk listing:
 
Nbr   Size Code   Name
   -++--+-
  1   1000.0 MiB   2700
  2   260.0 MiBEF00 EFI system partition
  3   128.0 MiB0C01Microsoft reserved part
  4   49.6 GiB 0700  Basic data partition
  5   9.7 GiB  2700Lenovo (?recovery?)
  6   10.0 GiB 8200   Linux SWAP
  7   49.4 GiB 8300   Archlinux /
  8   58.8 GiB 8300   /home
  9   1024.0 KiB   EF02 bios_grub (Ubuntu?)
 10   59.8 GiB 8300   UBUNTU /

It's the one marked EFI system partition (ESP).



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Installing Archlinux alongside Ubuntu on a Windows 8 UEFI laptop

[Daniel Micay]

On 01/05/14 06:15 PM, Alan E. Davis wrote:
 Ubuntu's kernel is on the / partition.  Would I move it to the ESP
 partition, in that case?
 
 And I will mount that partition on /mnt/boot ?
 
 I have never used gummiboot.  Since the Arch system is already to go, but
 not yet with a boot management setup, I should manually move that kernel to
 the ESP partition as well?
 
 Alan Davis

Yes, you should mount the ESP partition as /boot so the kernels get
installed there. Then install gummiboot and set up entries for Arch and
Ubuntu.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Installing Archlinux alongside Ubuntu on a Windows 8 UEFI laptop

[Daniel Micay]

On 01/05/14 06:20 PM, Alan E. Davis wrote:
 I see another level of complexity here, in a statement on a page about
 Gummiboot on the wiki:
 
 * Warning: *Gummiboot simply provides a boot menu for EFISTUB kernels. In
 case you have issues booting EFISTUB kernels like in
 FS#33745https://bugs.archlinux.org/task/33745,
 you should use a boot loader which does not use EFISTUB, like
 GRUBhttps://wiki.archlinux.org/index.php/GRUB,
 Syslinux https://wiki.archlinux.org/index.php/Syslinux or
 ELILOhttps://wiki.archlinux.org/index.php/Bootloaders#ELILO
 .
 
 Would grub work, using this, or a similar, approach?

gummiboot is far less complex than grub, so I'm not sure where you're
getting that from. The kernel's EFISTUB handling doesn't work on all
hardware, but it will most likely work fine for you. The whole point of
EFISTUB is that it's simpler/faster than the legacy way of doing it.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Installing Archlinux alongside Ubuntu on a Windows 8 UEFI laptop

[Daniel Micay]

On 01/05/14 06:31 PM, Alan E. Davis wrote:
 Do I need to install a special kernel?
 
 Thank you for the advice.
 
 Alan

No, you need to install gummiboot. That's all.



signature.asc
Description: OpenPGP digital signature