date:20171023

Struggling with vendors that cater mostly for MS Windows users who
don't really care about Secure Boot being disabled or not, is not the
way that leads to an available solution. Such vendors are far too
powerful to bow to the pressures of insignificant pressure groups like
'old fashioned' Linux users who do not want to use a 'modern
distribution'. What I would do, is dedicate a small partition to hold
a distribution that can actually boot in Secure Mode and I would use
that to manage my bootloader.

You have the choice of at least two major distributions that work
under Secure Boot. These are Ubuntu and Debian.

This solution was what I did when GRUB 2 started to behave obstinately
refusing to install its first stage when completely stripped of an
operating system.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] UEFI and Secure Boot

2017-10-23 Thread Enrico Weigelt, metux IT consult


On 23.10.2017 11:50, Simon Hobson wrote:


[U]EFI in itself isn't all that bad - what some manufacturers do with it, and 
the hash they make of it, is often bad.


It always had been bullshit. A good technical solution would be
OF + device tree.

Board vendors should just provide the board init code source + DT.
Or just use barebox or coreboot. For those who dont, just dont buy
their crap.


--mtx
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] UEFI and Secure Boot

2017-10-23 Thread golinux


On 2017-10-23 20:12, zap wrote:
firetools is how you use your web browser/internet connecting 
applications

your web browser is firefox based with the garbage disabled but still
regularly updated



fsmithred has a neat text interface for firejail at:

https://sourceforge.net/projects/refracta/files/Extras/firemenu-1.2.deb/download

Eliminates the garrish graphics of firetools

golinux

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] UEFI and Secure Boot

2017-10-23 Thread zap

On 10/23/2017 04:18 PM, Edward Bartolo wrote:
> Quote: "secure operating system"
>
> Where can I get that? Linux does have vulnerabilities. Together with
> that, a kernel alone doesn't do much. Other packages are needed which
> add up more attack surface area.
>
> You do remember when kernel.org itself was hacked without anyone
> noticing anything for seventeen days?
Nah, it was probably before I started using any form of linux.

but yeah, linux is a secure operating system IF, and this is a big if
you have some of these things:

a firewall like gufw or something better
you constantly update your packages when new updates arrive
noscript on your firefox based web browser (this is a given which no one
should avoid using)
firetools is how you use your web browser/internet connecting applications
your web browser is firefox based with the garbage disabled but still
regularly updated
you have a security focused linux distro (not ubuntu xD)
no blobs of any kind with regard to wifi especially!

Other things that would be helpful would of course not use pulseaudio or
systemd... . But meh... kind of hard not to use pulseaudio... systemd is
becoming a nightmare for many I am sure.

It is also notable that blobs are awful for security
I try to do all these things, and also you should use something like
librecmc or lede for your router.

Yes linux may have vulnerabilities, but they can be easily worked around
if you learn enough about ways to make your system more secure.

Not all of the vulnerabilities, but more than you think.

ps, I do most of the things I mentioned...  but I do not have a way to
remove pulseaudio yet as of now...

I would love to though given its security implications...

> https://lwn.net/Articles/457142/
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Secure boot switch in EFI

2017-10-23 Thread William C Vaughan

I'm unsure if this is the way for a lurker to reply to his list. If not, my
apologies. Someone posted that it would be nice to get a list of PC vendors
who don't allow disabling of secure boot. That would be a great boon if
someone can actually post such a list. I'm currently posting from a Dell
XPS-13, which I've had for a year and definitely allowed me to disable
secure boot prior to my Linux installs. Inquiring minds want to know, if
possible.

-- 
Move from rim to hub; know the wheel. - G. Buddha
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] UEFI and Secure Boot


> On Oct 23, 2017, at 6:44 PM, Rick Moen  wrote:
> 
> Quoting John Franklin (frank...@tux.org):
> 
> Technically, a rootkit is not a threat but rather a minor after-the-fact 
> sequel to a threat and succesful attack.  It does not embody an attack,
> itself.  Rather, it's a method of hiding from the legitimate
> administrator the covert activity of an intruder who has already
> achieved control of the system through other means.  
> 
> The taxonomy of 'malware' I include in
> http://linuxmafia.com/~rick/faq/#virus5 might be helpful.  

No arguments here against more precise language.

jf
-- 
John Franklin
frank...@tux.org





smime.p7s
Description: S/MIME cryptographic signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] UEFI and Secure Boot

2017-10-23 Thread Rick Moen

Quoting John Franklin (frank...@tux.org):

Technically, a rootkit is not a threat but rather a minor after-the-fact 
sequel to a threat and succesful attack.  It does not embody an attack,
itself.  Rather, it's a method of hiding from the legitimate
administrator the covert activity of an intruder who has already
achieved control of the system through other means.  

The taxonomy of 'malware' I include in
http://linuxmafia.com/~rick/faq/#virus5 might be helpful.  

I'm quibbling because the IT press, misguided on this particular point by
antimalware/security firms in pursuit of their commercial agenda, have
confused many this matter.  To quote from my virus essay:

  That incompetent reporting sometimes has extremely damaging
  consequences: In 2002, British authorities arrested [link] the alleged 
  author of the T0rn rootkit, based on their mistaken notion that it's a 
  "Linux virus". (My efforts to get the Reuters / NY Times story corrected 
  were ignored, except by cited anti-virus consultant Graham Cluley, who 
  told me he'd been misquoted.

(I was not intending to otherwise enter this discussion.  FWIW, 
I agree that code-signing has utility, modulo frequent issues over key
management.)

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] UEFI and Secure Boot


> On Oct 23, 2017, at 6:13 PM, Steve Litt  wrote:
> 
> 
> And by the way, I had a Win8 box that wouldn't accept Linux, but
> luckily it was for one of my kids who wanted Windows.
> 

Brand and model?  Why wouldn’t it accept Linux?

jf
-- 
John Franklin
frank...@tux.org





smime.p7s
Description: S/MIME cryptographic signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] UEFI and Secure Boot

> On Oct 23, 2017, at 5:34 PM, marc  wrote:
> 
>> kato...@freaknet.org writes:
>>> And what if you want to use your own unsigned bootloader? Why should
>>> you ask someone else the permission to boot your own machine? o_O
>> 
>> Because I want deny people with physical access the ability to boot unsigned
>> bootloaders.
>> 
>> I am both the owner of my hardware and the person who usually has physical
>> access. Requiring signed boot loaders is way to transfer rights from latter
>> role to someone else ??? in my case I'd prefer to transfer them to the
>> former for all portable hardware, so for my next laptop I'm going to do the
>> MOK stuff described on this list last week.
> 
> So I might be missing something, but I really don't get the point of
> having a signed boot infrastructure for the technically competent
> computer owner.
> 
> If you want to prevent somebody from booting some random unsigned
> code, then a BIOS from 1999 will do: You just configure the
> BIOS to boot your selected internal disk only and then set a password on
> the BIOS and the bootloader. Then nobody can insert a memory stick and boot
> their evil code. 

The threat is a rootkit: something that installs a new bootloader and/or kernel 
and/or kernel module that runs a keylogger or a C server or malware server or 
something.  The compromised kernel filters the results of certain system calls 
to hide the interlopers presence, so you, the “owner” of machine, are unaware 
they are there, even as root.  A BIOS password won’t stop that.

> If your threat model includes somebody who is capable of opening
> your computer and messing with its internals, then no amount
> of EFI will protect you - the bad guy can just replace your
> entire motherboard.

Physical security of the machine is a different layer, but signing kernels can 
frustrate the Bad Guy.  If they swap out the MB for one without a key, that is 
detectable by the end user.  If they swap out the MB with one that has their 
keys and not yours, you won’t be able to boot the next kernel you sign and 
install -- again, detectable.

That’s assuming they can get a MB in there that has the same serial numbers 
(see dmidecode).

> If you are worried that somebody who has
> compromised your OS remotely will hack your bootloader, then
> reconsider their motives: They are already on a running host OS
> as root and can look inside your encrypted disk volumes too -
> you have lost already.

Secureboot is there to prevent someone who has root access from installing a 
rootkit.  (see above)  “Looking inside” is bad enough, and kernel signing won’t 
prevent a Wordpress security flaw from letting them in.  It keeps them from 
compromising the kernel, the tool you rely on to see they are there. 

> As far as I can tell, signed bootloaders have advantages
> for people who need to roll out images to remote PCs via
> untrusted channels, and are worried that the people sitting
> in front of their PCs will install the "wrong" kernel. In other
> words, microsoft, large corporates and maybe even some linux
> distributions.

Yes, that is an advantage for them: making sure the kernels that are installed 
are the kernels they ship, and not something from a malware site or MitM’d 
during the update. Their tech support crew can easily tell the kernel is the 
right one because they can verify the signature. They’re producing a product 
just as Devuan is.  It makes sense they would want to protect it, and kernel 
signing is a good tool for that purpose.

> However, for those weirdos who like to own the computer
> they sit in front of, there is no benefit. Only downside:
> The kernel that enthusiasts build themselves is the "wrong" one to
> those who wish to lock down the computing world with DRM and
> related nonsense.

Since (as has been posted) you can sign your own kernels, the enthusiast can do 
the same thing corporate tech support can do: verify no one has updated his 
kernel on him with one he didn’t build.  Installing a MOK (Machine Owner Key) 
in the firmware and removing the keys that shipped with the machine ensures 
that the enthusiast truly owns the machine.

jf
-- 
John Franklin
frank...@tux.org

smime.p7s
Description: S/MIME cryptographic signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] UEFI and Secure Boot

2017-10-23 Thread Steve Litt

On Mon, 23 Oct 2017 15:42:00 -0400
John Franklin  wrote:

> > On Oct 23, 2017, at 2:37 PM, goli...@dyne.org wrote:
> > 
> > On 2017-10-23 09:41, Steve Litt wrote:  
> >> To get Windows 10 certification, you have to have Secure Boot but
> >> there's no requirement for an off switch.
> >> SteveT  
> > 
> > If that is true, it sounds like a class action law suit to me.
> > Anyone want to take it on?  
> 
> Can you identify any vendors where you can’t install Linux?  If you
> can’t, this just a bunch of FUD.

So you proclaim.

But in fact, given past behavior of Microsoft, Redhat, and the hardware
vendors, the mere possibility of this elevates it way above FUD, to a
serious concern.

And by the way, I had a Win8 box that wouldn't accept Linux, but
luckily it was for one of my kids who wanted Windows.

SteveT

Steve Litt 
October 2017 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] UEFI and Secure Boot

2017-10-23 Thread marc

> kato...@freaknet.org writes:
> >And what if you want to use your own unsigned bootloader? Why should
> >you ask someone else the permission to boot your own machine? o_O
> 
> Because I want deny people with physical access the ability to boot unsigned
> bootloaders.
> 
> I am both the owner of my hardware and the person who usually has physical
> access. Requiring signed boot loaders is way to transfer rights from latter
> role to someone else ??? in my case I'd prefer to transfer them to the
> former for all portable hardware, so for my next laptop I'm going to do the
> MOK stuff described on this list last week.

So I might be missing something, but I really don't get the point of
having a signed boot infrastructure for the technically competent
computer owner.

If you want to prevent somebody from booting some random unsigned
code, then a BIOS from 1999 will do: You just configure the
BIOS to boot your selected internal disk only and then set a password on
the BIOS and the bootloader. Then nobody can insert a memory stick and boot
their evil code. 

If your threat model includes somebody who is capable of opening
your computer and messing with its internals, then no amount
of EFI will protect you - the bad guy can just replace your
entire motherboard. If you are worried that somebody who has
compromised your OS remotely will hack your bootloader, then
reconsider their motives: They are already on a running host OS
as root and can look inside your encrypted disk volumes too -
you have lost already.

As far as I can tell, signed bootloaders have advantages
for people who need to roll out images to remote PCs via
untrusted channels, and are worried that the people sitting
in front of their PCs will install the "wrong" kernel. In other
words, microsoft, large corporates and maybe even some linux
distributions. However, for those weirdos who like to own the computer
they sit in front of, there is no benefit. Only downside:
The kernel that enthusiasts build themselves is the "wrong" one to
those who wish to lock down the computing world with DRM and
related nonsense.

regards

marc

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] UEFI and Secure Boot

Quote: "secure operating system"

Where can I get that? Linux does have vulnerabilities. Together with
that, a kernel alone doesn't do much. Other packages are needed which
add up more attack surface area.

You do remember when kernel.org itself was hacked without anyone
noticing anything for seventeen days?

https://lwn.net/Articles/457142/
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] UEFI and Secure Boot

2017-10-23 Thread zap


>> If that is true, it sounds like a class action law suit to me.  Anyone want 
>> to take it on?
> Can you identify any vendors where you can’t install Linux?  If you can’t, 
> this just a bunch of FUD.
>
> jf
>

It sounds like something that windows 10 vendors would love to do. The
idea of anyone having a secure operating system scares them for whatever
reason...


>
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] UEFI and Secure Boot


> On Oct 23, 2017, at 2:37 PM, goli...@dyne.org wrote:
> 
> On 2017-10-23 09:41, Steve Litt wrote:
>> To get Windows 10 certification, you have to have Secure Boot but
>> there's no requirement for an off switch.
>> SteveT
> 
> If that is true, it sounds like a class action law suit to me.  Anyone want 
> to take it on?

Can you identify any vendors where you can’t install Linux?  If you can’t, this 
just a bunch of FUD.

jf
-- 
John Franklin
frank...@tux.org





smime.p7s
Description: S/MIME cryptographic signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Trouble with apt-get upgrade over TOR

2017-10-23 Thread lpb+devuan

I'm having trouble doing an "apt-get upgrade" over tor+http. The update
works fine; my guess is the manifests have bad information. Here's what
a session looks like (see below). Am I doing something wrong?

I would have posted this to the bug tracker but I'm not sure to which
package to assign it.

Get:1 tor+http://devuanfwojg73k6r.onion jessie InRelease
Get:2 tor+http://devuanfwojg73k6r.onion jessie-updates InRelease
Get:3 tor+http://devuanfwojg73k6r.onion jessie-security InRelease
Get:4 tor+http://devuanfwojg73k6r.onion jessie/main amd64 Packages
Hit tor+http://devuanfwojg73k6r.onion jessie/main amd64 Packages

Hit tor+http://devuanfwojg73k6r.onion jessie/contrib amd64 Packages

Get:5 tor+http://devuanfwojg73k6r.onion jessie/contrib Translation-en_US

Hit tor+http://devuanfwojg73k6r.onion jessie-updates/main amd64 Packages

Hit tor+http://devuanfwojg73k6r.onion jessie-updates/contrib amd64
Packages
Get:6 tor+http://devuanfwojg73k6r.onion jessie-updates/contrib
Translation-en_US
Hit tor+http://devuanfwojg73k6r.onion jessie-security/main amd64
Packages
Hit tor+http://devuanfwojg73k6r.onion jessie-security/contrib amd64
Packages
Get:7 tor+http://devuanfwojg73k6r.onion jessie-security/contrib
Translation-en_US
Ign tor+http://devuanfwojg73k6r.onion jessie/contrib Translation-en_US

Ign tor+http://devuanfwojg73k6r.onion jessie/contrib Translation-en

Ign tor+http://devuanfwojg73k6r.onion jessie/main Translation-en_US

Ign tor+http://devuanfwojg73k6r.onion jessie/main Translation-en

Ign tor+http://devuanfwojg73k6r.onion jessie-updates/contrib
Translation-en_US
Ign tor+http://devuanfwojg73k6r.onion jessie-updates/contrib
Translation-en
Ign tor+http://devuanfwojg73k6r.onion jessie-updates/main
Translation-en_US
Ign tor+http://devuanfwojg73k6r.onion jessie-updates/main Translation-en

Ign tor+http://devuanfwojg73k6r.onion jessie-security/contrib
Translation-en_US
Ign tor+http://devuanfwojg73k6r.onion jessie-security/contrib
Translation-en
Ign tor+http://devuanfwojg73k6r.onion jessie-security/main
Translation-en_US
Ign tor+http://devuanfwojg73k6r.onion jessie-security/main Translation-en
Fetched 156 kB in 30s (5,086 B/s)
Reading package lists... Done
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
  libmysqlclient18 mysql-client-5.5 mysql-common mysql-server
mysql-server-5.5
  mysql-server-core-5.5 xserver-common xserver-xorg-core
8 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 12.5 MB of archives.
After this operation, 33.8 kB disk space will be freed.
Do you want to continue? [Y/n]
Err tor+http://devuanfwojg73k6r.onion/merged/ jessie-security/main
mysql-common all 5.5.58-0+deb8u1
  Can't complete SOCKS5 connection to 0.0.0.0:0. (1)
Err tor+http://devuanfwojg73k6r.onion/merged/ jessie-security/main
libmysqlclient18 amd64 5.5.58-0+deb8u1
  Can't complete SOCKS5 connection to 0.0.0.0:0. (1)
Err tor+http://devuanfwojg73k6r.onion/merged/ jessie-security/main
mysql-server all 5.5.58-0+deb8u1
  Failed to receive SOCKS5 connect request ack.
Err tor+http://devuanfwojg73k6r.onion/merged/ jessie-security/main
mysql-server-5.5 amd64 5.5.58-0+deb8u1
  Can't complete SOCKS5 connection to 0.0.0.0:0. (1)
Err tor+http://devuanfwojg73k6r.onion/merged/ jessie-security/main
mysql-client-5.5 amd64 5.5.58-0+deb8u1
  Can't complete SOCKS5 connection to 0.0.0.0:0. (1)
Err tor+http://devuanfwojg73k6r.onion/merged/ jessie-security/main
mysql-server-core-5.5 amd64 5.5.58-0+deb8u1
  Can't complete SOCKS5 connection to 0.0.0.0:0. (1)
Err tor+http://devuanfwojg73k6r.onion/merged/ jessie-security/main
xserver-common all 2:1.16.4-1+deb8u2
  Can't complete SOCKS5 connection to 0.0.0.0:0. (1)
Err tor+http://devuanfwojg73k6r.onion/merged/ jessie-security/main
xserver-xorg-core amd64 2:1.16.4-1+deb8u2
  Can't complete SOCKS5 connection to 0.0.0.0:0. (1)
E: Failed to fetch
tor+http://devuanfwojg73k6r.onion/merged/pool/DEBIAN-SECURITY/updates/main/m/mysql-5.5/mysql-common_5.5.58-0+deb8u1_all.deb
 Can't complete SOCKS5 connection to 0.0.0.0:0. (1)

E: Failed to fetch
tor+http://devuanfwojg73k6r.onion/merged/pool/DEBIAN-SECURITY/updates/main/m/mysql-5.5/libmysqlclient18_5.5.58-0+deb8u1_amd64.deb
 Can't complete SOCKS5 connection to 0.0.0.0:0. (1)

E: Failed to fetch
tor+http://devuanfwojg73k6r.onion/merged/pool/DEBIAN-SECURITY/updates/main/m/mysql-5.5/mysql-server_5.5.58-0+deb8u1_all.deb
 Failed to receive SOCKS5 connect request ack.

E: Failed to fetch
tor+http://devuanfwojg73k6r.onion/merged/pool/DEBIAN-SECURITY/updates/main/m/mysql-5.5/mysql-server-5.5_5.5.58-0+deb8u1_amd64.deb
 Can't complete SOCKS5 connection to 0.0.0.0:0. (1)

E: Failed to fetch
tor+http://devuanfwojg73k6r.onion/merged/pool/DEBIAN-SECURITY/updates/main/m/mysql-5.5/mysql-client-5.5_5.5.58-0+deb8u1_amd64.deb
 Can't complete SOCKS5 connection to 0.0.0.0:0. (1)

E: Failed to fetch

Re: [DNG] UEFI and Secure Boot

2017-10-23 Thread golinux


On 2017-10-23 09:41, Steve Litt wrote:


To get Windows 10 certification, you have to have Secure Boot but
there's no requirement for an off switch.

SteveT



If that is true, it sounds like a class action law suit to me.  Anyone 
want to take it on?


golinux
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] UEFI and Secure Boot

2017-10-23 Thread Adam Borowski

On Mon, Oct 23, 2017 at 10:41:29AM -0400, Steve Litt wrote:
> On Mon, 23 Oct 2017 10:50:54 +0100
> Simon Hobson  wrote:
> 
> 
> > Two ways :
> > 1) You simply turn off secure boot and it'll boot your unsigned
> > binary. If your machine doesn't have that then it's a bug and you
> > should complain to the retailer - and return the machine (which by
> > now is not in a re-sellable condition) as not fit for purpose (you
> > did mention the need to boot unsigned binaries when buying it didn't
> > you ?) AIUI, part of MS's specs for manufacturers is that they allow
> > secure boot to be disabled - precisely to head off the "this machine
> > can only run Windows, monopoly abuse, ..." arguments.
> 
> The preceding paragraph was true of Windows 8 certification on
> Intel/AMD motherboards: To get Windows 8 certification you had to have
> Secure Boot and it had to have an off switch.
> 
> To get Windows 10 certification, you have to have Secure Boot but
> there's no requirement for an off switch.

Also, begging Microsoft to have your distribution's key signed is also not
guaranteed to work.  There are two keys:
* "Microsoft Windows Production PCA 2011" that must be included
* "Microsoft Corporation UEFI CA 2011" that "on non-Windows RT PCs the OEM
  should consider" -- not only some machines are explicitly excluded, but
  on others it's merely "should consider".

Microsoft controls almost 100% of non-server PC manufacturers by the means
of volume discounts: the official price is insanely high, effectively
excluding any manufacturer who doesn't comply.  Even worse, as non-niche
manufacturers all sell a variant with Windows (that's where the vast
majority of sales is), they don't have the freedom of offering a variant
that respects the user, on the pain of losing the volume discount.

The discounts are invariably negotiated in secret.  Ie, you can have all new
machines drop support for big-distros overnight.

Specs:
https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance#SignatureDatabase

-- 
⢀⣴⠾⠻⢶⣦⠀ Laws we want back: Poland, Dz.U. 1921 nr.30 poz.177 (also Dz.U. 
⣾⠁⢰⠒⠀⣿⡁ 1920 nr.11 poz.61): Art.2: An official, guilty of accepting a gift
⢿⡄⠘⠷⠚⠋⠀ or another material benefit, or a promise thereof, [in matters
⠈⠳⣄ relevant to duties], shall be punished by death by shooting.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] UEFI and Secure Boot


Didier Kryn writes:
I've read previously on this list that secureboot doesn't 
prevent booting from a usb key... Or did I misunderstood?


People spread too much FUD.

Various people have asserted, without naming names, that some/most vendors 
do not allow you to delete keys from the list of accepted keys. If you can 
control the list of keys, and your own key is the only one you accept, then 
you can prevent booting from USB sticks.


(I won't post any more in this thread now; nothing new is going to be said 
anyway. Sigh.)


Arnt

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] UEFI and Secure Boot

2017-10-23 Thread Didier Kryn


Le 23/10/2017 à 16:35, Arnt Gulbrandsen a écrit :

Didier Kryn writes:

For me the things which need to be protected are

1) the data
2) the OS, to avoid backdoors

I can't see any need to protect a motherboard against booting 
from a "foreign" disk.


To access the data: Boot from foreign media, modify or replace the 
usual boot partition so it looks right until it asks for the disk 
encryption password, turn off the host, wait for the owner to turn it 
on and type in the password, done. 


I've read previously on this list that secureboot doesn't prevent 
booting from a usb key... Or did I misunderstood?


Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] UEFI and Secure Boot

2017-10-23 Thread Narcis Garcia

El 23/10/17 a les 16:35, Arnt Gulbrandsen ha escrit:
> Didier Kryn writes:
>>     For me the things which need to be protected are
>>
>>     1) the data
>>     2) the OS, to avoid backdoors
>>
>>     I can't see any need to protect a motherboard against booting from
>> a "foreign" disk.
> 
> To access the data: Boot from foreign media, modify or replace the usual
> boot partition so it looks right until it asks for the disk encryption
> password, turn off the host, wait for the owner to turn it on and type
> in the password, done.
> 

I don't know better secure boot than your own removable media: MBR and
whole /boot on an USB key, and full disk encryption.
If you really need that level of security, don't trust to any installed
boot (UEFI/GRUB/etc).

Mainboard support for UEFIs aren't capable to trust the boot so
transparently as FOSS does.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] UEFI and Secure Boot

2017-10-23 Thread Steve Litt

On Mon, 23 Oct 2017 10:50:54 +0100
Simon Hobson  wrote:


> Two ways :
> 1) You simply turn off secure boot and it'll boot your unsigned
> binary. If your machine doesn't have that then it's a bug and you
> should complain to the retailer - and return the machine (which by
> now is not in a re-sellable condition) as not fit for purpose (you
> did mention the need to boot unsigned binaries when buying it didn't
> you ?) AIUI, part of MS's specs for manufacturers is that they allow
> secure boot to be disabled - precisely to head off the "this machine
> can only run Windows, monopoly abuse, ..." arguments.

The preceding paragraph was true of Windows 8 certification on
Intel/AMD motherboards: To get Windows 8 certification you had to have
Secure Boot and it had to have an off switch.

To get Windows 10 certification, you have to have Secure Boot but
there's no requirement for an off switch.

SteveT

Steve Litt 
October 2017 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] UEFI and Secure Boot


taii...@gmx.com writes:

No you aren't.

Intel ME + "Secure" boot non-owner controlled firmware code 
signing enforcement (probably hardware enforced via boot guard, 
so one couldn't even spend the thousands to have it removed via 
a coreboot platform port)


If you can't execute whatever you please on all the processors 
then it isn't yours.


It sounds good when you put it like that. But you're telling someone who 
has added an easter egg to a very widely used open source package, and 
noone ever found it. I didn't even try to hide or obfuscate that, still, 
noone ever found it (or at least mentioned it on any of the relevant lists 
etc). I know a maintainer who put something controversial in the code he 
was maintaining, too. None of his users noticed until he removed it 
himself.


He and I could both put code on millions of people's systems that none of 
them discovered. He hid his stuff in an unrelated commit, I didn't bother 
even with that. Noone noticed. That's how effective open source is at 
revealing to hardware owners what software they actually run.


You personally don't even known to within a factor of ten how many lines of 
source code are installed on your most-used linux box. Am I right? 
Closed-software users don't know, you don't know either. The control you 
think you have is mostly an illusion.


Arnt

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] UEFI and Secure Boot


Didier Kryn writes:

For me the things which need to be protected are

1) the data
2) the OS, to avoid backdoors

I can't see any need to protect a motherboard against 
booting from a "foreign" disk.


To access the data: Boot from foreign media, modify or replace the usual 
boot partition so it looks right until it asks for the disk encryption 
password, turn off the host, wait for the owner to turn it on and type in 
the password, done.


Arnt

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Debian testing drop redis non systemd

2017-10-23 Thread John Hughes


On 23/10/17 15:59, Patrick Meade wrote:



As John Hughes said, this isn't quite as bad as we originally thought. 
We can still run redis-server with the Debian provided sysvinit 
script, and Debian isn't throwing away upstream files for no reason.


Also note that the upstream init script example doesn't support the 
Debian hook scripts.  Perhaps upstream don't think that's useful 
functionality?




However, it's not all sunshine and flowers either. The daemon state 
change hooks are removed in the latest Debian package. If someone had 
a script that pre-loaded data into the redis cache on daemon start, or 
fired off a backup of the persistent store on daemon stop, these 
scripts would no longer be called when redis goes up/down.


Given that there is no documentation for these scripts other than the 
Debian changelog is anyone using them?


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Debian testing drop redis non systemd

2017-10-23 Thread Patrick Meade

On 10/23/2017 04:10 AM, John Hughes wrote:

On 21/10/17 01:53, Patrick Meade wrote:

That text is not from the Debian changelog, but rather from debian/NEWS.

Ah, didn't notice that. Always trust the code before the doc.

Still don't understand why it says "in favour of systemd's ... commands"
when the patch does no such thing.

The only way I can understand it is as a poorly phrased way of saying
"we're dropping this feature, systemd users could do something to work
around that". I guess he could have added suggestions for sysvinit and
upstart users as well. But in no way does this patch somehow remove
sysvinit support for redis in Debian.

The GitHub commit is here:

https://github.com/lamby/pkg-redis/commit/6a9e4d0142b45195a0d55945bbc558df4c48707b#diff-e2b5949461a30128734d213f0ead1565

I must admit that I'm still learning the ropes with respect to Debian
packaging. Could you explain this diff of debian/redis-server.init to me?

What's to explain? It "drops the Debian-specific support for the
/etc/redis/redis-{server}.sentinel.{pre,post}-{up,down}.d directories"
by removing the calls to run-parts.

tl;dr:
- Neither redis-server 3.2.6 nor redis-server 4.0.2 provide the upstream
sysvinit examples
- redis-server 4.0.2 still has support for sysvinit commands in
etc/init.d/redis-server

- redis-server 4.0.2 removes the pre/post up/down hooks for sysvinit
- hopefully, we can ask Debian maintainer to revert, if not, we have
work ahead

Okay, I got a chance to dig into redis-server a little bit this morning.
I unpacked the stretch version of the package (3.2.6), and the
buster/sid version of the package (4.0.2):

http://http.us.debian.org/debian/pool/main/r/redis/redis-server_3.2.6-1_amd64.deb

http://http.us.debian.org/debian/pool/main/r/redis/redis-server_4.0.2-3_amd64.deb

ar x package.deb
tar xvf data.tar.xz
fgrep -R "init.d" *

I then looked into the files identified by the fgrep command.

redis-server 3.2.6 reports:

etc/init.d/redis-server: echo "Usage: /etc/init.d/$NAME
{start|stop|restart|force-reload|status}" >&2
etc/redis/redis-server.post-up.d/00_example:# "/etc/init.d/redis-server
start" does not result in unintended consequences.
etc/redis/redis-server.pre-up.d/00_example:# "/etc/init.d/redis-server
start" does not result in unintended consequences.
etc/redis/redis-server.post-down.d/00_example:#
"/etc/init.d/redis-server start" does not result in unintended consequences.
etc/redis/redis-server.pre-down.d/00_example:# "/etc/init.d/redis-server
start" does not result in unintended consequences.

redis-server 4.0.2 reports:

etc/init.d/redis-server: echo "Usage: /etc/init.d/$NAME
{start|stop|restart|force-reload|status}" >&2

I checked etc/init.d/redis-server against the upstream sysvinit examples:

https://github.com/antirez/redis/blob/unstable/utils/redis_init_script

https://github.com/antirez/redis/blob/unstable/utils/redis_init_script.tpl

The file provided upstream is an example script to start/stop in the
sysvinit style. In Debian, this file is neither included nor used.
Debian has its own custom script that relies on /sbin/start-stop-daemon
to manage daemon state.

The next task was to figure out what the changes to
etc/init.d/redis-server were doing. The Run_parts function and calls to
it are removed from the Debian script. This means the pre/post up/down
hook calls are removed when the daemon changes state.

The other files etc/redis/redis-server.{NEW_STATE}.d/00_example are just
empty stubs that give advice on how hook scripts should be written.
redis-server 4.0.2 removes these, because the pre/post up/down hooks are
removed, so the examples would advertise functionality that doesn't
exist any more.

Final takeaways:

- redis-server 4.0.2 still works with sysvinit; you can start/stop the
redis service per normal with the script that still exists in 4.0.2

- redis-server 4.0.2 did NOT remove upstream redis sysvinit scripts.
Upstream DOES provide an example script, but Debian DOES NOT include or
use that script. Debian has its own script.

- redis-server 4.0.2 support for sysvinit is LESS FUNCTIONAL than
redis-server 3.2.6; in particular, with 3.2.6, you can write pre/post
up/down hook scripts that get called by the sysvinit system. In 4.0.2
these scripts (if present) would be non-functional in the sysvinit system.

- The text from debian/NEWS, amended by the Debian maintainer in a later
commit, reads:

This version drops the Debian-specific support for the
/etc/redis/redis-{server,sentinel}.{pre,post}-{up,down}.d directories in
favour of using systemd's ExecStartPre, ExecStartPost, ExecStopPre,
ExecStopPost commands.

The meaning of this is: "We're dropping calls to the sysvinit hook
scripts. systemd already runs hook scripts via ExecStartPre,
ExecStartPost, ExecStopPre, ExecStopPost".

As John Hughes said, this isn't quite as bad as we originally thought.
We can still run redis-server with the

Re: [DNG] UEFI and Secure Boot

2017-10-23 Thread Didier Kryn


Le 23/10/2017 à 11:47, Arnt Gulbrandsen a écrit :


Because I want deny people with physical access the ability to boot 
unsigned bootloaders.


I am both the owner of my hardware and the person who usually has 
physical access. Requiring signed boot loaders is way to transfer 
rights from latter role to someone else — in my case I'd prefer to 
transfer them to the former for all portable hardware, so for my next 
laptop I'm going to do the MOK stuff described on this list last week.


For me the things which need to be protected are

1) the data

2) the OS, to avoid backdoors

I can't see any need to protect a motherboard against booting from 
a "foreign" disk.


The only way to protect a computer from a physical hack is to lock 
the door of the room where it sits, with a good old key made of iron.


Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] many many 404 when upgrading/installing packages

On Mon, Oct 23, 2017 at 01:15:08PM +, Fulano Diego Perez wrote:
> 
> 
> KatolaZ:
> >  # apt-get update
> > 
> > before trying to install/upgrade packages? One reason why you might
> > have a 404 is that the cache kept by apt is older than the actual
> > version. 
> 
> dont be sorry.
> 
> yes, did the obvious updates ..

OK. Could you please retry and report which packages give a 404, and
also post the relevant sections of your sources.list?

Thanks

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]


signature.asc
Description: Digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] many many 404 when upgrading/installing packages

2017-10-23 Thread Fulano Diego Perez



KatolaZ:
>  # apt-get update
> 
> before trying to install/upgrade packages? One reason why you might
> have a 404 is that the cache kept by apt is older than the actual
> version. 

dont be sorry.

yes, did the obvious updates ..
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] many many 404 when upgrading/installing packages

On Mon, Oct 23, 2017 at 12:34:45PM +, Fulano Diego Perez wrote:
> hi
> 
> recently installed devuan jessie LTS - many thank yous for the project
> 
> im not new to 'nix but am i missing something when i can't install
> libreoffice or qemu completely ?
> 
> dont have that computer handy now, sorry, but id say atleast 30-50%
> packages/dependencies are 404
> 
> using tor+https repos
> 
> something's not right
> 

Hi,

sorry if my question sounds lame: have you run

 # apt-get update

before trying to install/upgrade packages? One reason why you might
have a 404 is that the cache kept by apt is older than the actual
version. 

HND

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]


signature.asc
Description: Digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] many many 404 when upgrading/installing packages

2017-10-23 Thread Fulano Diego Perez

hi

recently installed devuan jessie LTS - many thank yous for the project

im not new to 'nix but am i missing something when i can't install
libreoffice or qemu completely ?

dont have that computer handy now, sorry, but id say atleast 30-50%
packages/dependencies are 404

using tor+https repos

something's not right

?
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] UEFI and Secure Boot


kato...@freaknet.org writes:

Yes, but what about *adding* your own keys? This does not seem to be a
popular option, AFAIK.


Of course it isn't. Who has a reason to talk about it?

Microsoft doesn't talk much about that, because Microsoft wants most users 
to use Windows Upgrade and get timely upgrades. They document what people 
like us need, and their corporate salespeople will tell their corporate 
customers how to guard against industrial espionate, but their message in 
public is naturally about the common case: MAKE WINDOWS USERS UPGRADE 
AUTOMATICALLY.


The people who maintain UEFI-related software for linux won't talk much 
about it, beacuse they're employed to make things like Ubuntu work 
smoothly. At the end of a long day making UEFI work with Ubuntu out of the 
box, they may wrote a blog post or post on linux-kernel, and show an 
example of something. That something's very likely going to be about the 
stuff they did at work that day, not about the opposite.


The individuals who wrote the spec and code may all be friendly to people 
like yourself, but friendliness is not attention. They have little reason 
to talk about your usecase.


Arnt

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] UEFI and Secure Boot

On Mon, Oct 23, 2017 at 11:16:50AM +0100, Arnt Gulbrandsen wrote:
> kato...@freaknet.org writes:
> >I don't know much about signed bootloaders, and i will try to re-read
> >the thread to fully understand your statement.
> 
> The short version: You can remove keys, so that only your own key is valid
> for booting. If you're then careful about that key, then later physical
> access is almost useless.
> 

Yes, but what about *adding* your own keys? This does not seem to be a
popular option, AFAIK.

My2Cents

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]


signature.asc
Description: Digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] UEFI and Secure Boot


kato...@freaknet.org writes:

I don't know much about signed bootloaders, and i will try to re-read
the thread to fully understand your statement.


The short version: You can remove keys, so that only your own key is valid 
for booting. If you're then careful about that key, then later physical 
access is almost useless.


I personally think that works as described. If the vendors add secret 
backdoor keys and it's ever revealed, big corporate customers like Siemens 
and Petrobras will scream at them, a prospect vendors prefer to avoid.


Arnt

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] UEFI and Secure Boot

On Mon, Oct 23, 2017 at 10:50:54AM +0100, Simon Hobson wrote:
> KatolaZ  wrote:
> 
> > And what if you want to use your own unsigned bootloader? Why should
> > you ask someone else the permission to boot your own machine? o_O
> 
> Two ways :
> 1) You simply turn off secure boot and it'll boot your unsigned binary. If 
> your machine doesn't have that then it's a bug and you should complain to the 
> retailer - and return the machine (which by now is not in a re-sellable 
> condition) as not fit for purpose (you did mention the need to boot unsigned 
> binaries when buying it didn't you ?) AIUI, part of MS's specs for 
> manufacturers is that they allow secure boot to be disabled - precisely to 
> head off the "this machine can only run Windows, monopoly abuse, ..." 
> arguments.
> 
> 2) You create your own key, install that in the system, and sign your binary 
> with that key. This means that the machine will still boot Windows 8+ which 
> won't otherwise boot.
> Again, if the machine won't allow the installation of your own key then 
> that's a bug - it's (AIUI) part of the UEFI spec to allow keys to be added.
> 
> [U]EFI in itself isn't all that bad - what some manufacturers do with it, and 
> the hash they make of it, is often bad.
> 

The problem is that, AFAIK, the norm for many producers is to allow 1)
and disallow 2) so far. But again, I have no extensive experience
here, so will revert back to silence ;)

HND

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]


signature.asc
Description: Digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] UEFI and Secure Boot

2017-10-23 Thread taii...@gmx.com


On 10/23/2017 05:47 AM, Arnt Gulbrandsen wrote:


kato...@freaknet.org writes:

And what if you want to use your own unsigned bootloader? Why should
you ask someone else the permission to boot your own machine? o_O


Because I want deny people with physical access the ability to boot 
unsigned bootloaders.
I think we can make a distinction here between owner controlled devices 
[1] with a fully open source firmware that implements the code signing 
mechanism that you desire and install such as grub's kernel signing 
features vs one that is controlled by the vendor/OEM instead of you.


[1](ex: talos 2, kcma-d8/kgpe-d16)


I am both the owner of my hardware

No you aren't.

Intel ME + "Secure" boot non-owner controlled firmware code signing 
enforcement (probably hardware enforced via boot guard, so one couldn't 
even spend the thousands to have it removed via a coreboot platform port)


If you can't execute whatever you please on all the processors then it 
isn't yours.


I imagine "secure" boot v3.0 will have MS no longer signing linux 
bootloaders at all (unless you buy an expensive "business" PC).

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] UEFI and Secure Boot

On Mon, Oct 23, 2017 at 10:47:31AM +0100, Arnt Gulbrandsen wrote:
> kato...@freaknet.org writes:
> >And what if you want to use your own unsigned bootloader? Why should
> >you ask someone else the permission to boot your own machine? o_O
> 
> Because I want deny people with physical access the ability to boot unsigned
> bootloaders.

Those people with physical access to your machine might get signed
bootloaders, e.g., by someone authorised to sign bootloaders on behalf
of NSA :)

> 
> I am both the owner of my hardware and the person who usually has physical
> access. Requiring signed boot loaders is way to transfer rights from latter
> role to someone else — in my case I'd prefer to transfer them to the former
> for all portable hardware, so for my next laptop I'm going to do the MOK
> stuff described on this list last week.
> 

I don't know much about signed bootloaders, and i will try to re-read
the thread to fully understand your statement.

Thanks!

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]


signature.asc
Description: Digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] UEFI and Secure Boot

2017-10-23 Thread Simon Hobson

KatolaZ  wrote:

> And what if you want to use your own unsigned bootloader? Why should
> you ask someone else the permission to boot your own machine? o_O

Two ways :
1) You simply turn off secure boot and it'll boot your unsigned binary. If your 
machine doesn't have that then it's a bug and you should complain to the 
retailer - and return the machine (which by now is not in a re-sellable 
condition) as not fit for purpose (you did mention the need to boot unsigned 
binaries when buying it didn't you ?) AIUI, part of MS's specs for 
manufacturers is that they allow secure boot to be disabled - precisely to head 
off the "this machine can only run Windows, monopoly abuse, ..." arguments.

2) You create your own key, install that in the system, and sign your binary 
with that key. This means that the machine will still boot Windows 8+ which 
won't otherwise boot.
Again, if the machine won't allow the installation of your own key then that's 
a bug - it's (AIUI) part of the UEFI spec to allow keys to be added.

[U]EFI in itself isn't all that bad - what some manufacturers do with it, and 
the hash they make of it, is often bad.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] UEFI and Secure Boot


kato...@freaknet.org writes:

And what if you want to use your own unsigned bootloader? Why should
you ask someone else the permission to boot your own machine? o_O


Because I want deny people with physical access the ability to boot 
unsigned bootloaders.


I am both the owner of my hardware and the person who usually has physical 
access. Requiring signed boot loaders is way to transfer rights from latter 
role to someone else — in my case I'd prefer to transfer them to the former 
for all portable hardware, so for my next laptop I'm going to do the MOK 
stuff described on this list last week.


Arnt

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] UEFI and Secure Boot

On Mon, Oct 23, 2017 at 11:24:12AM +0200, Edward Bartolo wrote:
> Contrary to the main argumentative line of this thread, I found EFI
> far better than BIOS booting. The fact that a dedicated partition is
> used to hold the primary boot loaders, is a great advantage. With
> BIOS, the booloader was placed in the first sector's initial 446 bytes
> of data with the remaining defining the partition table of just 64
> bits. Furthermore, additional data was also written where the
> bootloader's second stage main executable was saved on disk.
> 
> EFI is as simple as placing the bootloader's first state in the EFI
> System Partition. This is much simpler. I haven't tried secure boot
> with Linux, but using a signed primary bootloader from distributions
> that offer that, should solve the problem.

And what if you want to use your own unsigned bootloader? Why should
you ask someone else the permission to boot your own machine? o_O

HND

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]


signature.asc
Description: Digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] UEFI and Secure Boot

Contrary to the main argumentative line of this thread, I found EFI
far better than BIOS booting. The fact that a dedicated partition is
used to hold the primary boot loaders, is a great advantage. With
BIOS, the booloader was placed in the first sector's initial 446 bytes
of data with the remaining defining the partition table of just 64
bits. Furthermore, additional data was also written where the
bootloader's second stage main executable was saved on disk.

EFI is as simple as placing the bootloader's first state in the EFI
System Partition. This is much simpler. I haven't tried secure boot
with Linux, but using a signed primary bootloader from distributions
that offer that, should solve the problem.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Debian testing drop redis non systemd

2017-10-23 Thread John Hughes




On 21/10/17 01:53, Patrick Meade wrote:


That text is not from the Debian changelog, but rather from debian/NEWS.


Ah, didn't notice that.  Always trust the code before the doc.

Still don't understand why it says "in favour of systemd's ... commands" 
when the patch does no such thing.


The only way I can understand it is as a poorly phrased way of saying 
"we're dropping this feature, systemd users could do something to work 
around that".  I guess he could have added suggestions for sysvinit and 
upstart users as well.  But in no way does this patch somehow remove 
sysvinit support for redis in Debian.




The GitHub commit is here:

https://github.com/lamby/pkg-redis/commit/6a9e4d0142b45195a0d55945bbc558df4c48707b#diff-e2b5949461a30128734d213f0ead1565 



I must admit that I'm still learning the ropes with respect to Debian 
packaging. Could you explain this diff of debian/redis-server.init to me?




What's to explain?  It "drops the Debian-specific support for the 
/etc/redis/redis-{server}.sentinel.{pre,post}-{up,down}.d directories" 
by removing the calls to run-parts.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Debian testing drop redis non systemd

2017-10-23 Thread John Hughes


On 22/10/17 11:37, Jaromil wrote:

Thanks everyone for adding details,

On Fri, 20 Oct 2017, Patrick Meade wrote:


https://github.com/lamby/pkg-redis/commit/6a9e4d0142b45195a0d55945bbc558df4c48707b#diff-9e388da7cd119765989cc22d2bc07e5c

This diff clearly shows that redis-sentinel example scripts provided
by upstream redis developers for compatibility with sysvinit are being
*deleted* from the package, de facto removing even the documentation
on how to start/stop from init.d despite it being just an example.

The scripts that are removed:


+rm_conffile /etc/redis/redis-sentinel.pre-up.d/00_example 4:4.0.2-3~

+rm_conffile /etc/redis/redis-sentinel.pre-down.d/00_example 4:4.0.2-3~

+rm_conffile /etc/redis/redis-sentinel.post-up.d/00_example 4:4.0.2-3~

+rm_conffile /etc/redis/redis-sentinel.post-down.d/00_example 4:4.0.2-3~


Do not exist in the upstream distribution of redis, *which does not 
include sysvinit scripts*.


They were added by the Debian redis developers as part of a poorly 
documented feature (only mentioned in the changelog!) which only exists 
on Debian.


Debian still include sysvinit scripts for redis, which provide as much 
functionality as sysvinit can give.  (The systemd service files allow 
running multiple copies of redis.  The Debian provided sysvinit scripts 
never allowed this, the only way of doing it would be for the user to 
write his own init scripts, which will be much easier to do without the 
{pre,post}-{up,down} complexity),


it is even worse than I initially thought.

No, it isn't.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] amprolla3 testing -- bug found and fixed

Dear All,

thanks a lot for your effort in helping battle-testing amprolla3. We
have several dozen distinct IPs currently using amprolla3, and we had
already the first bug report and fix on Saturday night/Sunday morning
(thanks to Arnt and Olaf for reporting, and to parazyd for fixing it)
:)

Due to a glitch in repo config (and a bug in amprolla3), people who
had ascii-backports in their sources.list and apt-get upgraded using
amprolla3 before yesterday afternoon (Sunday Oct. 22nd, 13:00 CEST)
might have got unwanted packages from stretch-backports.

If you are among those and you think your system might be affected, no
need to panic: there is a simple procedure to revert all those
packages back to pure Devuan stuff, using two easy (and temporary)
pins, and 4 commands. We have tested it and it works. Just shout if
this is the case, and we will report the procedure here and/or on
dev1galaxy, as needed.

Please continue using amprolla3 as much as possible, so that we can
cover as many corner-cases as possible.

Sorry for any inconvenience caused by this glitch, and thanks again
for your precious continued efforts in helping making Devuan a free,
stable, dependable universal operating system.

HND

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]


signature.asc
Description: Digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Amprolla3 is out for testing