Re: [gentoo-user] TPM feature - do I need it?
On Sunday 30 Nov 2014 03:21:16 Rich Freeman wrote: On Sat, Nov 29, 2014 at 6:44 PM, Mick michaelkintz...@gmail.com wrote: Thanks Rich, Also, what happens if the TPM chip, or the whole MoBo blows up? Will I ever be able to access my data using another PC? Only if you encrypted it. A TPM chip doesn't do much more than except store and retrieve data, and digitally sign things. It just tends to be used in a way that greatly limits the ability of arbitrary processes to access the data stored on the chip. With Linux you're basically completely in control. You choose to encrypt your drive and store the key in the TPM, and you instruct the TPM to only hand it over under the conditions you specify, such as a particular bootloader, kernel, and initramfs (or something like that - I've never implemented it myself). If somebody tries to boot your system with some other kernel/bootloader/initramfs then the TPM will not have the valid signature chain and it will refuse to divulge your full-disk encryption key. I imagine that you could generate the key outside the TPM and keep a copy of it somewhere and load it into the TPM, so that if you mess up you can just mount it manually. OK, but as I understand it although I can set up a passhphrase for the private key stored by the current oligopoly of manufacturers in a TPM, I can't extract it from the TPM. Would this mean that I will have no means of decrypting my drive, if I lose the TPM hardware module (e.g. due to hardware failure, fire, theft, etc.)? Access to my data will then become conditional on my having access to this unique TPM piece of silicon and its manufacturer's installed key, besides any private key passwd that I would have set up. Have I got this wrong, or is it that the TPM private key is merely the CA root certificate's key and I won't need this, unless I am creating/revoking user keys? Is there a way of using the user key separately and offline (on different hardware) without verification by the CA root certificate? Hmm ... I wonder if dm-crypt, LUKS and friends are a better way to achieve data protection for Linux users, without using some manufacturer's suspect certification credentials. I guess as long as I don't *have* to use Trusted Computing™, I won't care too much if it is on the MoBo. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Debian forked, because of systemd brouhaha
Am , schrieb Bill Kenworthy: I read Veteran Unix Admins collective as a category that old style admin types fall into - the background being that systemd is essentially the old guard, do things based on experience and good practice vs the new guard whose use case is throw away vm's that are not expected to hang around, we don't care amateurs. I am a native English speaker, maybe that's why you missed it? Yes, it is a category and no, I didn't miss that point. The point though is that the way this fork was being announced is quite simple the worst way to do it. The announcement was not signed by any name and just made by someone named Majordomo Debianfork. Not that's why I do call a bad way to start such a project and building trust. Then they are already asking for donations. Yes, of course such a project has the need for donations, true. But would you spend someone money where you've got no clue whom you are giving it? I won't. So until they are going to publish a list of names about who's behind this project I for myself am just going to think about it as a more or less nice reminder to the Debian community about that a nother fork with the implicit goal to eliminate Systemd would quite quickly gain much momentum and speed. The goal of such a prank? To make the people think about it and change their opinion that this would not happen. Well, we are for sure going to see sooner or later, what's the real deal about Devuan.
Re: [gentoo-user] OT somehow: experiences around linode
Am 30.11.2014 um 00:57 schrieb Al: Stefan G. Weichinger wrote: Who has rent a virtual server at linode.com and what is your opinion? I have two servers with Linode, one running Gentoo, and Debian on the other. My experience has been great so far. My only contact with support was an ipv6 issue that I ran into a few months ago, and they quickly replied with a reference to a Gentoo bug which included the fix. So here's one vote for Linode. What's the bootloader in their gentoo image? no grub(2) at all! There is a talk of pv-grub in their docs ... can you simply install grub2 over it and be done?
Re: [gentoo-user] OT somehow: experiences around linode
On 30 November 2014 11:45:21 CET, Stefan G. Weichinger li...@xunil.at wrote: Am 30.11.2014 um 00:57 schrieb Al: Stefan G. Weichinger wrote: Who has rent a virtual server at linode.com and what is your opinion? I have two servers with Linode, one running Gentoo, and Debian on the other. My experience has been great so far. My only contact with support was an ipv6 issue that I ran into a few months ago, and they quickly replied with a reference to a Gentoo bug which included the fix. So here's one vote for Linode. What's the bootloader in their gentoo image? no grub(2) at all! There is a talk of pv-grub in their docs ... can you simply install grub2 over it and be done? No, pv-grub is run inside the context of the host, using a kernel image inside the VM. -- Joost -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-user] OT somehow: experiences around linode
Am 30.11.2014 um 11:57 schrieb J. Roeleveld: No, pv-grub is run inside the context of the host, using a kernel image inside the VM. ... which is not in /boot as far as I see. So if I want to add kernel-boot-time-options I have to install my own kernel plus the entry in menu.lst, correct? Thanks!
[gentoo-user] Empty sync
Hello list, Well, that was novel. Yesterday when I ran emerge --sync as usual, not a single file was transferred, other than timestamp.chk. I tried it again with a different mirror with the same result. I can't remember ever seeing that happen before. Today it was back to normal again. -- Rgds Peter.
Re: [gentoo-user] Debian forked, because of systemd brouhaha
141130 Marc Stürmer wrote: The point though is that the way this fork was being announced is quite simple the worst way to do it. The announcement was not signed by any name and just made by someone named Majordomo Debianfork. Not that's why I do call a bad way to start such a project and building trust. Then they are already asking for donations. Yes, of course such a project has the need for donations, true. But would you send someone money where you've got no clue whom you are giving it? I won't. So until they are going to publish a list of names about who's behind this project I for myself am just going to think about it as a more or less nice reminder to the Debian community about that a nother fork with the implicit goal to eliminate Systemd would quite quickly gain much momentum and speed. The goal of such a prank? To make the people think about it and change their opinion that this would not happen. A rather shrewd analysis ; the name 'Devuan' adds to my suspicions. -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-user] OT somehow: experiences around linode
On 18:00, Sun, Nov 30, 2014 Stefan G. Weichinger li...@xunil.at wrote: Am 30.11.2014 um 11:57 schrieb J. Roeleveld: No, pv-grub is run inside the context of the host, using a kernel image inside the VM. ... which is not in /boot as far as I see. So if I want to add kernel-boot-time-options I have to install my own kernel plus the entry in menu.lst, correct? Thanks! Correct. pv-grub is a script in dom0 that will attempt to read the menu.lst in /boot of the VM, and based on that file, initialize a domU with the referred kernel (residing in /boot), passing all boot time options to the kernel. It performs magic tricks to read the /boot proper, because / might be on a different partition or even different virtual disk, but 99% of the time it works automagically. It's the 1% that you should be scared of :-) Rgds, --
Re: [gentoo-user] OT somehow: experiences around linode
Am 30.11.2014 um 12:49 schrieb Pandu Poluan: It performs magic tricks to read the /boot proper, because / might be on a different partition or even different virtual disk, but 99% of the time it works automagically. It's the 1% that you should be scared of :-) Ah, at least something! ;-) Is it possible to somehow set kernel options for the existing kernel image (without building one)? I'd just like to modify init= ...
Re: [gentoo-user] Debian forked, because of systemd brouhaha
On 30/11/14 12:35, Andrew Savchenko wrote: On Sat, 29 Nov 2014 22:32:18 -0500 Rich Freeman wrote: On Sat, Nov 29, 2014 at 9:01 PM, Bill Kenworthy bi...@iinet.net.au wrote: I am already really annoyed that by default systemd and apps designed to work with it leave traces on openrc based systems. You're getting worked up about text files and filenames. I suppose you'll be really upset that bash completion files are now being installed by default, and packages install logrotate configs and cron scripts even if you don't use logrotate or cron. We have INSTALL_MASK for such cases. While it should be used with care (as improper use will broke system), INSTALL_MASK=*/systemd/* keeps my systems clean from this filthy abomination. Sure, we could add a million more layers of conditionals to everything and you might save a few dozen inodes on your 10GB install, at the cost of lots of hassle/bugs/etc. In general Gentoo tends to take the pragmatic approach. If you're a purist of just about any kind you're going to have to hold your nose. However, this cuts both ways - the purists who don't want YOU to be able to make the choices YOU want to make also have to hold their noses. :) Best regards, Andrew Savchenko Yes I am using install masking ... but I believe there was a comment that this could break things as some programs expected to see the files in the systemd directories. Hence my comment. And about being a purist and holding my nose ... no I am not ... but I do not like useless cruft just because it was the easy way out which was my impression of the conversation on the email list - hence INSTASL_MASLK. BillK
Re: [gentoo-user] Debian forked, because of systemd brouhaha
Am 30.11.2014 um 12:44 schrieb Philip Webb: A rather shrewd analysis ; the name 'Devuan' adds to my suspicions. Well, the people behind it claim to be mostly from Italy and this should be pronounced like DevOne. People so far who have published their names do include: - Franco Lanza (who fixed a misconfiguration at the nginx setup of devuan.org he claimed) and - Teodoro Santoni, who claimed to be a junior-jack-of-all-trades in the original VUA group, going to be a maintainer of whatever is going to be needed. Source: https://lists.dyne.org/lurker/thread/20141127.212941.f55acc3a.en.html#20141127.212941.f55acc3a This still leaves quite in the dark who's the initiator behind it, which kind of leadership there's at the moment - or is there none? And, of course, the possible other people being involved so far.
Re: [gentoo-user] Debian forked, because of systemd brouhaha
On Sunday 30 Nov 2014 12:29:07 Marc Stürmer wrote: Am 30.11.2014 um 12:44 schrieb Philip Webb: A rather shrewd analysis ; the name 'Devuan' adds to my suspicions. Well, the people behind it claim to be mostly from Italy and this should be pronounced like DevOne. People so far who have published their names do include: - Franco Lanza (who fixed a misconfiguration at the nginx setup of devuan.org he claimed) and - Teodoro Santoni, who claimed to be a junior-jack-of-all-trades in the original VUA group, going to be a maintainer of whatever is going to be needed. Source: https://lists.dyne.org/lurker/thread/20141127.212941.f55acc3a.en.html#20141 127.212941.f55acc3a This still leaves quite in the dark who's the initiator behind it, which kind of leadership there's at the moment - or is there none? And, of course, the possible other people being involved so far. The request for funding when not much code has been written yet makes me suspicious. Nevertheless, I support moving away from a RHL sponsored monolithic binary and hopefully if not today it will happen eventually. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Debian forked, because of systemd brouhaha
On Sun, 30 Nov 2014 13:01:33 +, Mick wrote: Nevertheless, I support moving away from a RHL sponsored monolithic binary and hopefully if not today it will happen eventually. systemd isn't monolithic so I can only assume you are referring to the Linux kernel here :) Red Hat open source everything, so while they can pay for the development of the code, they can never own it. Yes, their money gives them control of what is and is not developed by those they are paying, but it gives them neither exclusive rights to code nor the right to exclude code. -- Neil Bothwick Never sleep with anyone crazier than yourself. pgpuvBt0l5ziy.pgp Description: OpenPGP digital signature
Re: [gentoo-user] OT somehow: experiences around linode
Am 30.11.2014 um 12:59 schrieb Stefan G. Weichinger: Am 30.11.2014 um 12:49 schrieb Pandu Poluan: It performs magic tricks to read the /boot proper, because / might be on a different partition or even different virtual disk, but 99% of the time it works automagically. It's the 1% that you should be scared of :-) Ah, at least something! ;-) Is it possible to somehow set kernel options for the existing kernel image (without building one)? I'd just like to modify init= ... Solved, thanks!
Re: [gentoo-user] TPM feature - do I need it?
On Sun, Nov 30, 2014 at 4:41 AM, Mick michaelkintz...@gmail.com wrote: OK, but as I understand it although I can set up a passhphrase for the private key stored by the current oligopoly of manufacturers in a TPM, I can't extract it from the TPM. Would this mean that I will have no means of decrypting my drive, if I lose the TPM hardware module (e.g. due to hardware failure, fire, theft, etc.)? Access to my data will then become conditional on my having access to this unique TPM piece of silicon and its manufacturer's installed key, besides any private key passwd that I would have set up. I'm not an expert on TPM, but I suspect you could generate the key outside the TPM, save a copy somewhere safe, and then load the key into the TPM and secure it. Hmm ... I wonder if dm-crypt, LUKS and friends are a better way to achieve data protection for Linux users, without using some manufacturer's suspect certification credentials. Encrypting a hard drive does not require trusting any key/certificate issued by a manufacturer. The advantage of using a TPM is that you can secure the drive without requiring a boot-time key to unlock the drive. This would be particularly useful if the system runs daemons that you might want to have run without anybody logging in. Also, using LUKS/etc requires a manually-entered key which will always be limited in entropy (mitigated using multiple rounds typically). The TPM is most useful in corporate environments though, since it doesn't require the PC owner to trust the PC user to not lose the key/etc. The whole point of the TPM is to reduce the risk of somebody who has physical possession of a machine compromising its security. In the corporate environment, the system owner often doesn't have physical control over the machine, and doesn't want to tell the user the encryption key which they can then proceed to write on a post-it stuck to the laptop. Those concerns apply just as much to a linux desktop as a windows one. Sadly, only ChromeOS really seems to take advantage of these capabilities in the linux desktop world. The whole Trusted Computing thing tends to turn off a lot of the linux community, much like UEFI is associated with thinks like unrootable devices. However, when used PROPERLY they're great tools. It is wrong for a device manufacturer to prevent a device owner from rooting a device they own. On the other hand, it is a great feature for a device owner to be able to prevent somebody who steals the device from being able to root it, or to block malware. The key is to keep control in the hands of the legitimate owner. -- Rich
[gentoo-user] Purpose of bashcomp_alias in bash-completion-r1.eclass?
Good day! Before reporting a bug I wanted to hear other opinions on that: In bash-completion-r1.eclass, what is the true purpose of bashcomp_alias? For now I only see error messages when trying to eselect bashcomp enable two aliases of the same script because of the same linkname. What benefit could one gain in aliasing their completion script to differnet names? In fact I find this confusing and highly contradicting, because you obviously can enable only one alias at the same time, but actually with enabling one you automatically enable all the others, since they are symlinks. Then why even bothering with those aliases? (Actual example: app-text/calibre-1.48-r1, which installs 14 or so aliases to the exact same completion script.) -- Flo
[gentoo-user] Re: flag details
Frank Steinmetzger Warp_7 at gmx.de writes: A tool with perhaps more detail or that parse the ebuild/sources for even greater detail information? I was out of country so couldn't read mail the last few days. My answer to your question: ufed This program seems very little known around the list. It doesn't give you more detail than euse, but it shows you what is available in an easy to view (and edit!) list. Very cool! Nice format. Like I wrote previously, a greater granularity of information too. Maybe something that parses out runtime and compile time information related to the flag settings, even if it only works after a given package is installed. Maybe a preprocessor (parser) that diffs the code that is to be compiled, with and without a given flag selected? Or at leaast references additional code. Other ideas for the basis of an advance mechanism is of interest to me. thx, James
[gentoo-user] Re: Purpose of bashcomp_alias in bash-completion-r1.eclass?
Florian Gamböck ml at floga.de writes: Before reporting a bug I wanted to hear other opinions on that: In bash-completion-r1.eclass, what is the true purpose of bashcomp_alias? There was a detailed discussion in gentoo-dev that is excellent reading on this issue: [gentoo-dev] [news item review] bash-completion-2.1-r90, version 2 circa 11/10/14. hth, James
Re: [gentoo-user] Re: Purpose of bashcomp_alias in bash-completion-r1.eclass?
Am 30.11.2014 um 16:27 schrieb James: [gentoo-dev] [news item review] bash-completion-2.1-r90, version 2 circa 11/10/14. Thank you, that was really worth reading. I'm not completely convinced yet, but it may be a starting point for further investigations. -- Flo
Re: [gentoo-user] Debian forked, because of systemd brouhaha
On Sunday 30 Nov 2014 13:13:02 Neil Bothwick wrote: On Sun, 30 Nov 2014 13:01:33 +, Mick wrote: Nevertheless, I support moving away from a RHL sponsored monolithic binary and hopefully if not today it will happen eventually. systemd isn't monolithic so I can only assume you are referring to the Linux kernel here :) I was actually referring to the systemd takeover. I know currently the incursion is in userspace, but soon enough I would expect them to try it on the kernel too. ;-) Red Hat open source everything, so while they can pay for the development of the code, they can never own it. Yes, their money gives them control of what is and is not developed by those they are paying, but it gives them neither exclusive rights to code nor the right to exclude code. Sure, but by applying Microsoft's monopolistic lessons they can have us all in a stranglehold before you know it: http://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish :-p -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Debian forked, because of systemd brouhaha
On 11/30/2014 05:13 AM, Neil Bothwick wrote: systemd isn't monolithic so I can only assume you are referring to the Linux kernel here :) systemd most certainly is monolithic as well as modular. You can't run journald without systemd and you most certainly can't replace journald with a third party binary. Dan
Re: [gentoo-user] Debian forked, because of systemd brouhaha
Am 30.11.2014 um 17:39 schrieb Daniel Frey: systemd most certainly is monolithic as well as modular. You can't run journald without systemd and you most certainly can't replace journald with a third party binary. IMHO this type of discussion leads to nowhere. Of course you can view it like that or the other way around and both sides will be always right, and if saying it's monolithic, well, so is X11 which is also not quite unixy to speak of. But it is accepted. Even if you view systemd as modular as possible, it will not solve the other problems for you, if you've got them with that kind of software, and for most people that's Lennart Poettering, his track record of software, his ego and GNOME attitude (my way or the high way). YMMV.
Re: [gentoo-user] TPM feature - do I need it?
On 29/11/14 19:53, Mick wrote: I'm looking to buy a new PC and while looking at FM2+ MoBos I saw ASUS offers one with a TPM feature. It also sells it as a separate component it seems: http://us.estore.asus.com/index.php?l=product_detailp=5793 I recall reading in this list about it, but I am not sure if it offers any benefits to me as a user, or just adds a layer of complexity without any substantial benefit. Your views and experience with this TPM thingy? one thing that is very useful is using tpm to feed random number generator $ time dd if=/dev/random of=/dev/null bs=1 count=100 100+0 records in 100+0 records out 100 bytes (100 B) copied, 26.7494 s, 0.0 kB/s real0m26.751s user0m0.000s sys0m0.001s after starting trousers and rngd is much much much faster for real(er) random $ time dd if=/dev/random of=/dev/null bs=1 count=100 100+0 records in 100+0 records out 100 bytes (100 B) copied, 0.000275625 s, 363 kB/s real0m0.001s user0m0.002s sys0m0.000s it's also a safer place to drop keys into for example for use with grub trustedgrub and basically does secureboot without the need for uefi you can also use it to encrypt/decrypt *if* you trust it is not backdoored but does mean you can use it for LUKS instead of say a GPG crypted pass file - or you can have the tpm crypt your password into gibberish and then that gibberish phrase is the real password for LUKS
Re: [gentoo-user] Debian forked, because of systemd brouhaha
On Sun, 30 Nov 2014 16:33:23 +, Mick wrote: Red Hat open source everything, so while they can pay for the development of the code, they can never own it. Yes, their money gives them control of what is and is not developed by those they are paying, but it gives them neither exclusive rights to code nor the right to exclude code. Sure, but by applying Microsoft's monopolistic lessons they can have us all in a stranglehold before you know it: http://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish The very title of this thread shows that that need not happen... Red Hat can only control what goes in Red Hat, not Linux at large. That's why, even though they are the largest contributor to the kernel, their distro's kernel is heavily patched. -- Neil Bothwick I've got a mind like a... a... what's that thing called? pgp8fq7IoX73S.pgp Description: OpenPGP digital signature
Re: [gentoo-user] TPM feature - do I need it?
On Sunday 30 Nov 2014 19:05:52 thegeezer wrote: *if* you trust it is not backdoored Well, yes, in the post Snowden era I do not trust it. At all. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] TPM feature - do I need it?
On Sun, Nov 30, 2014 at 5:19 PM, Mick michaelkintz...@gmail.com wrote: On Sunday 30 Nov 2014 19:05:52 thegeezer wrote: *if* you trust it is not backdoored Well, yes, in the post Snowden era I do not trust it. At all. Keep in mind that you have to consider your threat model. I think it is fairly likely that the NSA has backdoors into most TPM chips (I'm not sure I'd even limit that to US-made chips). On the other hand, I also consider it likely that the NSA has zero-days for every browser around, and likely privilege escalation attacks against linux, and maybe even attacks against most of the hypervisors out there. If the NSA REALLY wanted your data, then they're going to get it. Of course, some attacks are a larger concern than others. Actually accessing a TPM back-door, or utilizing a zero-day, likely requires actively modifying your internet traffic, which carries a risk of detection. They won't hesitate to do that if they are on the trail of some terrorist, but they probably won't do that as part of some kind of widespread surveillance net since there would be a pretty high likelihood of detection if they did that to everybody, and then they lose their zero-day. On the other hand, if TPM-seeded random numbers aren't really random then they might be able to passively decode your SSL traffic which is something that would be almost impossible to detect, and that could be done as part of an effort to read everybody's TCP streams. Honestly, I don't really worry about the NSA. If they want to read my traffic they're going to do it, and the only way to stop them would be to wrap so much tinfoil around my head that I basically couldn't interact with anybody online. I'm more concerned with things like identity theft, cryptolocker, physical theft of laptops, and so on. A TPM provides a significant level of protection against some of these attacks. LUKS does as well, but at a cost of convenience and a risk of downtime if you're running it on a server and it ends up rebooting when you aren't around. Why would you care about full-disk encryption on a server? Well, ever have a hard disk die on you? Can you guarantee that when a hard drive dies that you'll always have the ability to wipe it before returning it for a warranty swap? With full disk crypto you're safe even if you can't wipe it. -- Rich
[gentoo-user] Re: Debian forked, because of systemd brouhaha
On Sun, 30 Nov 2014 07:43:21 +0300 Andrew Savchenko birc...@gentoo.org wrote: On Sat, 29 Nov 2014 17:32:08 +0100 Marc Stürmer wrote: Am 29.11.2014 um 11:11 schrieb Pandu Poluan: What do you think, people? Shouldn't we offer them our eudev project to assist? Since Eudev has always been opensource under the GPLv2, like udev too, there's no need to /offer/ it. If they choose to use it, they can use it, no offer/questions necessary. Simple. As far as I understand, Pandu meant we can recommend them to use, but not some offer in commercial or proprietary terms. They've added something called devuan-eudev to their github workspace today, https://github.com/devuan/devuan-eudev. It would be nice if there could be one eudev project with the aim of supporting Gentoo, Devuan, and whatever other distros want to use it. Or if there must be multiple eudevs, it would be nice if the different teams could communicate and maybe take some patches from each other. (I'm no dev, so take my opinions on what would be nice for development with a chunk of salt.)
