Re: [arch-general] Instructions to mount efivars as readonly should be linked to in Beginner's Guide

[Tomasz Kramkowski]

On Mon, Feb 01, 2016 at 11:11:14AM -0600, Doug Newgard wrote:
> On Mon, 01 Feb 2016 22:27:01 +0530
> Jayesh Badwaik  wrote:
> 
> > Hi,
> > 
> > I have read the dangers of mounting efivars as writable recently, and I 
> > think 
> > there should be an entry in the archlinux installation guide and beginner's 
> > guide which should say exactly what is said in the warning in [1], and then 
> > link to [1] for further instructions. 
> > 
> 
> The "dangers" are only if you do something dumb and your firmware is equally
> dumb. Even then, hopefully the kernel will take care of it.
> https://gist.github.com/mjg59/8d9d494da56fbe6d8992

Since when does "do something dumb" and "potentially hard brick your
motherboard" become synonymous when speaking in terms of computers?

There's doing something dumb (by accident or otherwise) and then there's
bricking your motherboard, people make accidents all the time but since
modern day computers are quite nice and rugged, the only losses are data
losses.

I might shed a few tears over the loss of some not-backed up data, but I
would be quite a bit more pissed off if I lost a valuable and expensive
piece of hardware (granted, it would have to have a misconfigured and
shitty EFI, but since when is "being misconfigured and shitty" a rare
occurance?).

The newbies this change is aimed for are exactly the sorts of people who
might unwittingly rm -rf /.

-- 
Tomasz Kramkowski | GPG: 40B037BA0A5B8680 | Web: https://the-tk.com/


signature.asc
Description: PGP signature

Re: [arch-general] Instructions to mount efivars as readonly should be linked to in Beginner's Guide

[Sean Greenslade]

On February 1, 2016 11:57:01 AM EST, Jayesh Badwaik 
 wrote:
>Hi,
>
>I have read the dangers of mounting efivars as writable recently, and I
>think 
>there should be an entry in the archlinux installation guide and
>beginner's 
>guide which should say exactly what is said in the warning in [1], and
>then 
>link to [1] for further instructions. 

Well, that's why it's a wiki. Make an account, then go ahead and make that 
change.

--Sean

Re: [arch-general] Instructions to mount efivars as readonly should be linked to in Beginner's Guide

[Doug Newgard]

On Mon, 01 Feb 2016 22:27:01 +0530
Jayesh Badwaik  wrote:

> Hi,
> 
> I have read the dangers of mounting efivars as writable recently, and I think 
> there should be an entry in the archlinux installation guide and beginner's 
> guide which should say exactly what is said in the warning in [1], and then 
> link to [1] for further instructions. 
> 

The "dangers" are only if you do something dumb and your firmware is equally
dumb. Even then, hopefully the kernel will take care of it.
https://gist.github.com/mjg59/8d9d494da56fbe6d8992

Re: [arch-general] pacman and hooks

[Magnus Therning]

Bruno Pagani writes:

> Le 01/02/2016 23:05, Magnus Therning a écrit :
>> I just noticed an email in this list mentioning that with pacman 5.0 we
>> know have support for hooks. I proceeded to look at the man pages for
>> /pacman/, /makepkg/, and /PKGBUILD/ but only found one mention of a
>> /hookdir/.
>>
>> Is there more information about this feature available somewhere?
>>
>> /M
>
> They are some bits here:
> https://wiki.archlinux.org/index.php/User:Allan/Pacman_Hooks
>
> I’m very interested in this feature, maybe I will be able to automate
> very nicely the job of localepurge.

Yes, I found that one. It just lacks an air of officialty about it ;)

I'm hoping it can be used to limit the re-building of the documentation
index for Haskell packages.

/M

-- 
Magnus Therning  OpenPGP: 0x927912051716CE39
email: mag...@therning.org   jabber: mag...@therning.org
twitter: magthe   http://therning.org/magnus

I invented the term Object-Oriented, and I can tell you I did not have
C++ in mind.
 -- Alan Kay


signature.asc
Description: PGP signature

[arch-general] pacman and hooks

[Magnus Therning]

I just noticed an email in this list mentioning that with pacman 5.0 we
know have support for hooks. I proceeded to look at the man pages for
/pacman/, /makepkg/, and /PKGBUILD/ but only found one mention of a
/hookdir/.

Is there more information about this feature available somewhere?

/M

-- 
Magnus Therning  OpenPGP: 0x927912051716CE39
email: mag...@therning.org   jabber: mag...@therning.org
twitter: magthe   http://therning.org/magnus

Do not meddle in the affairs of Wizards, for they are subtle and quick
to anger.
 -- J.R.R Tolkien


signature.asc
Description: PGP signature

Re: [arch-general] Instructions to mount efivars as readonly should be linked to in Beginner's Guide

[Thomas Bächler]

Am 01.02.2016 um 20:35 schrieb Tomasz Kramkowski:
> The newbies this change is aimed for are exactly the sorts of people who
> might unwittingly rm -rf /.

Arch Linux is not aimed at newbies.

There's been lots of panic over this issue, yet it took several years of
UEFI being in the field for someone to actually trigger it. I guess it
will be fixed in the kernel very soon. Until then we can calm down and
start panicking - every local privilege escalation bug is worse than
this stuff.




signature.asc
Description: OpenPGP digital signature

[arch-general] btrfs/snapper hook for pacman 5.0?

[Karol Babioch]

Hi all,

now with hooks newly introduced to pacman, are there already some useful
btrfs and/or snapper hooks available? At least a quick look-around in
the forums and with Google hasn't revealed anything yet.

Maybe I'm getting something wrong here, but in my understanding it
should be doable and probably is even a cool feature that other distros
/ package managers already provide.

Basically all we have to do is to create a snapshot before and after
each pacman invocation. However, after having a look at the
alpm-hooks(5) man page I'm not too sure what kind of trigger would make
the most sense here.

With the "recommended" btrfs / snapper subvolume layout, one could add
triggers for paths that should be backed up (e.g. /, /var/, etc.). On
the other hand the man page tells us that using the root directory as
trigger path is not recommended.

So has anyone already looked into this and has some thoughts on this?

Best regards,
Karol Babioch



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Instructions to mount efivars as readonly should be linked to in Beginner's Guide

[Kyle Terrien]

Tomasz Kramkowski wrote:
> Since when does "do something dumb" and "potentially hard brick your
> motherboard" become synonymous when speaking in terms of computers?
> 
> There's doing something dumb (by accident or otherwise) and then there's
> bricking your motherboard, people make accidents all the time but since
> modern day computers are quite nice and rugged, the only losses are data
> losses.

You would think that a modern day machine is nice and rugged, but with
EFI/UEFI, it isn't.  There are way too many moving gears involved.

The preboot environment has one primary task: find a bootable medium and
boot it.  Ideally, you should be able to configure it to tell it which
medium to boot from.  In the absence of a bootable medium, it should
throw an error.  Simple!

This is how things worked before EFI.  Sure, getting an OS to load was a
magic trick in the early days ("pulling oneself up by one's
bootstraps"), but today it is a finely honed procedure.  There is
nothing broken with this procedure.  (After all, it boots!)

Enter EFI and UEFI.  From my (somewhat limited) experience with EFI, it
seems like whoever designed it attempted to solve some fringe problem
while creating 5 more problems in its place.  Why do OSes need to modify
the boot order entries?  Why do some motherboards refuse to fallback to
legacy BIOS?  To make things worse, many hardware implementations are
buggy and cannot be fixed (because there are already thousands/millions
of units in production).

So, if you want a modern day computer to be rugged:

* Use legacy BIOS.  There is nothing wrong with it.
* Mount efivars (and related stuff) as ro by default.  I read the
  systemd bug [0], but I still don't understand why so many tools need
  to write to it.  How often do you need to change motherboard
  parameters after you get an OS set up?  At that point, POST should be
  "find a device and boot it".

> I might shed a few tears over the loss of some not-backed up data, but I
> would be quite a bit more pissed off if I lost a valuable and expensive
> piece of hardware (granted, it would have to have a misconfigured and
> shitty EFI, but since when is "being misconfigured and shitty" a rare
> occurance?).

I wish I could answer the philosophical question of whether rm should be
able to brick hardware.  I suggest someone mail Brian Kernighan, Robert
Pike, or Ken Thompson.  I would be really curious to hear what they
think about this efivars thing.

--Kyle

[0]: https://github.com/systemd/systemd/issues/2402



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] pacman and hooks

[Stefan Tatschner]

On 01.02.2016 23:05, Magnus Therning wrote:
> Is there more information about this feature available somewhere?

$ man 5 alpm-hooks

S

Re: [arch-general] Instructions to mount efivars as readonly should be linked to in Beginner's Guide

[Kyle Terrien]

Maarten de Vries wrote:
> On 1 February 2016 at 23:29, Leonid Isaev 
> wrote:
> 
>>
>> Also, how can you brick a machine by simply zeroing the harddrive?
>>
>>
> You can't (well, someone can probably think of a contrived situation where
> you could, there's always someone, but generally speaking). The problem is
> with removing certain UEFI variables in buggy UEFI implementations (which
> are all too common). But in this case (with buggy UEFI implementation) a
> simple rm -rf of the wrong directory can brick your motherboard.
> 
> -- Maarten

Interesting sidenote: In Android, all the system-level stuff is
segregated to /system, which is mounted as ro by default.  This is just
another layer of security.

--Kyle



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] pacman and hooks

[Bruno Pagani]

Le 01/02/2016 23:05, Magnus Therning a écrit :
> I just noticed an email in this list mentioning that with pacman 5.0 we
> know have support for hooks. I proceeded to look at the man pages for
> /pacman/, /makepkg/, and /PKGBUILD/ but only found one mention of a
> /hookdir/.
>
> Is there more information about this feature available somewhere?
>
> /M

They are some bits here:
https://wiki.archlinux.org/index.php/User:Allan/Pacman_Hooks

I’m very interested in this feature, maybe I will be able to automate
very nicely the job of localepurge.

Bruno



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Instructions to mount efivars as readonly should be linked to in Beginner's Guide

[Kyle Terrien]

Sebastiaan Lokhorst wrote:
> 2016-02-01 23:29 GMT+01:00 Leonid Isaev :
> 
>> On Mon, Feb 01, 2016 at 01:40:54PM -0800, Kyle Terrien wrote:
>>> Tomasz Kramkowski wrote:
>>> * Use legacy BIOS.  There is nothing wrong with it.
>> Exactly, I really don't understand this interest to UEFI (and don't mention
>> secureboot).
>>
> 
> Many new (OEM) machines do not support legacy BIOS.

And this is what is so obnoxious/stupid about the whole situation.

In their infinite wisdom, hardware manufacturers are writing broken
implementations of an over-engineered system with no way to fallback to
the tried/true system that has been around for decades.

And when problems are discovered, it is too late.  The systems are in
production, and it is much easier to blame the consumer for uninstalling
Windows than to admit there are millions of buggy boards in the wild.

I really hope some sanity will return to the world of pre-boot.

--Kyle



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Instructions to mount efivars as readonly should be linked to in Beginner's Guide

[Sebastiaan Lokhorst]

2016-02-01 23:29 GMT+01:00 Leonid Isaev :

> On Mon, Feb 01, 2016 at 01:40:54PM -0800, Kyle Terrien wrote:
> > Tomasz Kramkowski wrote:
> > * Use legacy BIOS.  There is nothing wrong with it.
> Exactly, I really don't understand this interest to UEFI (and don't mention
> secureboot).
>

Many new (OEM) machines do not support legacy BIOS.

Re: [arch-general] Instructions to mount efivars as readonly should be linked to in Beginner's Guide

[Leonid Isaev]

On Mon, Feb 01, 2016 at 01:40:54PM -0800, Kyle Terrien wrote:
> Tomasz Kramkowski wrote:
> > Since when does "do something dumb" and "potentially hard brick your
> > motherboard" become synonymous when speaking in terms of computers?
> > 
> > There's doing something dumb (by accident or otherwise) and then there's
> > bricking your motherboard, people make accidents all the time but since
> > modern day computers are quite nice and rugged, the only losses are data
> > losses.
 
> * Use legacy BIOS.  There is nothing wrong with it.

Exactly, I really don't understand this interest to UEFI (and don't mention
secureboot). 

Also, how can you brick a machine by simply zeroing the harddrive?

Cheers,
-- 
Leonid Isaev
GPG fingerprints: DA92 034D B4A8 EC51 7EA6  20DF 9291 EE8A 043C B8C4
  C0DF 20D0 C075 C3F1 E1BE  775A A7AE F6CB 164B 5A6D

Re: [arch-general] btrfs/snapper hook for pacman 5.0?

[Leonid Isaev]

On Mon, Feb 01, 2016 at 10:21:04PM +0100, Karol Babioch wrote:
> Hi all,
> 
> now with hooks newly introduced to pacman, are there already some useful
> btrfs and/or snapper hooks available? At least a quick look-around in
> the forums and with Google hasn't revealed anything yet.

What is the goal here?

Cheers,
-- 
Leonid Isaev
GPG fingerprints: DA92 034D B4A8 EC51 7EA6  20DF 9291 EE8A 043C B8C4
  C0DF 20D0 C075 C3F1 E1BE  775A A7AE F6CB 164B 5A6D

Re: [arch-general] Instructions to mount efivars as readonly should be linked to in Beginner's Guide

[Maarten de Vries]

On 1 February 2016 at 23:29, Leonid Isaev 
wrote:

>
> Also, how can you brick a machine by simply zeroing the harddrive?
>
>
​You can't (well, someone can probably think of a contrived situation where
you could, there's always someone, but generally speaking). The problem​ is
with removing certain UEFI variables in buggy UEFI implementations (which
are all too common). But in this case (with buggy UEFI implementation) a
simple rm -rf of the wrong directory can brick your motherboard.

-- Maarten​

Re: [arch-general] btrfs/snapper hook for pacman 5.0?

[Karol Babioch]

Hi,

Am 01.02.2016 um 23:30 schrieb Leonid Isaev:
> On Mon, Feb 01, 2016 at 10:21:04PM +0100, Karol Babioch wrote:
>> Hi all,
>>
>> now with hooks newly introduced to pacman, are there already some useful
>> btrfs and/or snapper hooks available? At least a quick look-around in
>> the forums and with Google hasn't revealed anything yet.
> 
> What is the goal here?

To have snapshots before and after pacman did any changes to the
filesystem (i.e. upgraded packages), so one can easily rollback to a
known good state in case of an error, and/or look at the difference
between two snapshots to figure out what might cause an issue.

You can find more information on snapper here [1]. There are appropriate
hooks for aptitude and YaST, so I'm now looking into getting this
functionality with Arch.

Best regards,
Karol Babioch

[1]: http://snapper.io/



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] btrfs/snapper hook for pacman 5.0?

[Andrew Gregory]

On 02/02/16 at 12:16am, Karol Babioch wrote:
> Hi,
> 
> Am 01.02.2016 um 23:30 schrieb Leonid Isaev:
> > On Mon, Feb 01, 2016 at 10:21:04PM +0100, Karol Babioch wrote:
> >> Hi all,
> >>
> >> now with hooks newly introduced to pacman, are there already some useful
> >> btrfs and/or snapper hooks available? At least a quick look-around in
> >> the forums and with Google hasn't revealed anything yet.
> > 
> > What is the goal here?
> 
> To have snapshots before and after pacman did any changes to the
> filesystem (i.e. upgraded packages), so one can easily rollback to a
> known good state in case of an error, and/or look at the difference
> between two snapshots to figure out what might cause an issue.
> 
> You can find more information on snapper here [1]. There are appropriate
> hooks for aptitude and YaST, so I'm now looking into getting this
> functionality with Arch.
> 
> Best regards,
> Karol Babioch
> 
> [1]: http://snapper.io/

https://github.com/andrewgregory/pachooks

apg

Re: [arch-general] opinion request about Firefox add-ons

[Eli Schwartz]

On 01/31/2016 01:32 PM, Sebastiaan Lokhorst wrote:
> I think everyone is missing the point: the firefox-adblock-plus package[1]
> is broken since it does not work with the latest version of Firefox.
> It should probably be dropped from the repositories. I've opened a bug
> report.[1]
> 
> [1] https://bugs.archlinux.org/task/47970
> 

See: https://bugs.archlinux.org/task/47395#comment143383

The current package is downloading the extension from the wrong location.

-- 
Eli Schwartz

Re: [arch-general] opinion request about Firefox add-ons

[Eli Schwartz]

On 01/31/2016 11:52 AM, Jonathan Roemer wrote:
> On Sun, 2016-01-31 at 11:45 -0500, Francis Gerund wrote:
>> is there a better idea?
>> Any opinions?
> 
> uBlock Origin
> https://addons.mozilla.org/en-US/firefox/addon/ublock-origin/
> 

Way to go on not answering the question in any way, shape, or form...

-- 
Eli Schwartz

Re: [arch-general] opinion request about Firefox add-ons

[Jens Adam]

Mon, 1 Feb 2016 09:46:33 -0500
Jonathan Roemer :

> On Mon, Feb 01, 2016 at 01:52:03AM -0500, Eli Schwartz wrote:
> > Way to go on not answering the question in any way, shape, or form...
> 
> uBlock Origin [blurp]

Again, this thread is not a discussion about add-ons, but what to do
about Mozilla's new policy of enforcing signing and how it affects
seperately packaged add-ons.

I won't collect all the relevant links again.

--byte


pgpb2Z9FMBmFm.pgp
Description: Digitale Signatur von OpenPGP

[arch-general] Instructions to mount efivars as readonly should be linked to in Beginner's Guide

[Jayesh Badwaik]

Hi,

I have read the dangers of mounting efivars as writable recently, and I think 
there should be an entry in the archlinux installation guide and beginner's 
guide which should say exactly what is said in the warning in [1], and then 
link to [1] for further instructions. 

-- 
Cheers
Jayesh Badwaik

[1] https://wiki.archlinux.org/index.php/
Unified_Extensible_Firmware_Interface#Mount_efivarfs

Re: [arch-general] Chromium Favorites Bar Partially Inoperative

[Martin S. Weber]

On 2016-01-31 18:11:24, Dutch Ingraham wrote:
> (...)

confirm chrome on awesome "right" (or 2ndary) monitor problems: This is
an awesome + multi-monitor + chromium problem, not your graphics driver.

folders in the bookmark bar do not track "pressed" status or track the
mouse at all.

I believe it's more of awesome + some dirty stuff chromium does that it
gets away in most other window managers because those aren't as awesome
as awesome is awesome.

I have observed this for at least half a year now, on different machines,
always chromium (or google-chrome) + awesome + multimonitor setup + using
the "secondary" monitor. Another thing is that chrome likes to draw itself
a couple pixes left and right of where it actually is so at times snaps
into the wrong screen in awesome.  Less awesome WMs will probably cover
this chromium bug as well. Just like the scum browser at times wants
to draw its own window decoration or implement its own window movement
(drag the title bar) ignoring the WM. It's not surprising chromium gets
it wrong, these devs are out of their native area of expertise when
doing WM-level stuff and I hope one day they'll learn to leave their
fingers off it.

Regards,
-Martin

Re: [arch-general] opinion request about Firefox add-ons

[Jonathan Roemer]

On Mon, Feb 01, 2016 at 01:52:03AM -0500, Eli Schwartz wrote:
> Way to go on not answering the question in any way, shape, or form...

uBlock Origin is a less resource intensive, more thorough solution than
Adblock Plus. The relevant performance statistics are below.

https://github.com/gorhill/uBlock#performance

https://github.com/gorhill/uBlock/wiki/uBlock-vs.-ABP:-efficiency-compared

Additionally, it contains none of the "acceptable ads" whitelisting that
Adblock Plus has added, and provides more privacy-protecting features,
if those are important.

As the user's current Adblock Plus solution is broken, and they
specifically asked for other opinions or options, I figured I would
offer them an objectively better adblocking experience within Firefox.
Both a release and developer version of uBlock Origin are signed and
available on the Firefox addons site.

Re: [arch-general] opinion request about Firefox add-ons

[Eli Schwartz]

On 02/01/2016 09:46 AM, Jonathan Roemer wrote:
> On Mon, Feb 01, 2016 at 01:52:03AM -0500, Eli Schwartz wrote:
>> Way to go on not answering the question in any way, shape, or form...
> 
> uBlock Origin [random screed follows]
> 
> As the user's current Adblock Plus solution is broken, and they
> specifically asked for other opinions or options, I figured I would
> offer them an objectively better adblocking experience within Firefox.
> Both a release and developer version of uBlock Origin are signed and
> available on the Firefox addons site.
> 

So I guess you really didn't read the user's post after all.

Or you would have noticed the part where he explicitly stated that
Adblock Plus works fine. In fact, Adblock Plus too has both Release and
Developer versions signed and available on the Firefox addons site.


What the user was talking about, is the firefox-adblock-plus package
from the Arch Linux community repos.
Which doesn't work, on account of not being from the Firefox addons site
and thus not being signed.
A problem which is already reported on the Arch Linux bugtracker (with a
fix).


Thus answering the user's question of "should I use the Arch Linux
package or simply install Adblock Plus from the Firefox addons website".


Thank you for your recommendation to install the firefox-ublock-origin
package as a replacement (or interim solution), unfortunately, I ran
into some trouble doing so, as there is no such thing...

-- 
Eli Schwartz

Re: [arch-general] btrfs/snapper hook for pacman 5.0?

[Leonid Isaev]

Hi,

On Tue, Feb 02, 2016 at 12:16:53AM +0100, Karol Babioch wrote:
> > What is the goal here?
> 
> To have snapshots before and after pacman did any changes to the
> filesystem (i.e. upgraded packages), so one can easily rollback to a
> known good state in case of an error, and/or look at the difference
> between two snapshots to figure out what might cause an issue.
> 
> You can find more information on snapper here [1]. There are appropriate
> hooks for aptitude and YaST, so I'm now looking into getting this
> functionality with Arch.

Thanks. But /boot can not be snapshot with this, right?

Cheers,
-- 
Leonid Isaev
GPG fingerprints: DA92 034D B4A8 EC51 7EA6  20DF 9291 EE8A 043C B8C4
  C0DF 20D0 C075 C3F1 E1BE  775A A7AE F6CB 164B 5A6D

Re: [arch-general] Instructions to mount efivars as readonly should be linked to in Beginner's Guide

[Doug Newgard]

On Mon, 1 Feb 2016 19:35:35 +
Tomasz Kramkowski  wrote:

> On Mon, Feb 01, 2016 at 11:11:14AM -0600, Doug Newgard wrote:
> > On Mon, 01 Feb 2016 22:27:01 +0530
> > Jayesh Badwaik  wrote:
> >   
> > > Hi,
> > > 
> > > I have read the dangers of mounting efivars as writable recently, and I 
> > > think 
> > > there should be an entry in the archlinux installation guide and 
> > > beginner's 
> > > guide which should say exactly what is said in the warning in [1], and 
> > > then 
> > > link to [1] for further instructions. 
> > >   
> > 
> > The "dangers" are only if you do something dumb and your firmware is equally
> > dumb. Even then, hopefully the kernel will take care of it.
> > https://gist.github.com/mjg59/8d9d494da56fbe6d8992  
> 
> Since when does "do something dumb" and "potentially hard brick your
> motherboard" become synonymous when speaking in terms of computers?

I never said it shouldn't be dealt with, I'm just saying all of the coverage is
really overblown. It's a very obscure set of circumstances that leads to this,
and it appears will be handled in the kernel. Let's move on now.

Re: [arch-general] Chromium Favorites Bar Partially Inoperative

[Dutch Ingraham]

On Mon, Feb 01, 2016 at 11:34:37AM +0100, Martin S. Weber wrote:
> On 2016-01-31 18:11:24, Dutch Ingraham wrote:
> > (...)
> 
> confirm chrome on awesome "right" (or 2ndary) monitor problems: This is
> an awesome + multi-monitor + chromium problem, not your graphics driver.
> 
> folders in the bookmark bar do not track "pressed" status or track the
> mouse at all.
> 
> I believe it's more of awesome + some dirty stuff chromium does that it
> gets away in most other window managers because those aren't as awesome
> as awesome is awesome.
> 
Thanks, Martin, for the confirmation.

I now also now agree that the source of the problem is likely not the driver
but "an awesome + multi-monitor + chromium problem."  I've had the chance
to set up a similar situation on a different computer running OpenBSD, which
uses a different driver and the problem exists there as well.