Re: [arch-general] LXDE on boot
John Dey jsde...@gmail.com writes: Hi, I have installed openbox and lxde on a Raspberry Pi and configured to automatically start on boot. When I login (GUI), I get a blank screen with a cursor. Not the usual LXDE screen with panel at bottom. When I right click on mouse, I am given options--some of the applications will start such as xterm but others libreoffice don't. I don't know where the log files are? Is there anyone that can give me a helping hand. Thanks. John This may be the same bug as this one: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760971 So you probably have to copy a panel from /etc/xdg/lxpanel to ~/.config/lxpanel/LXDE/panels/ Are you sure you installed libreoffice? On Arch the openbox menu has some standard applications even if they are not installed. signature.asc Description: PGP signature
[arch-general] gnupg 2.1 not stable
From gnupg.org: 2.0.26 is the stable version suggested for most users, 2.1.1 is the brand-new modern version with support for ECC and many other new features, and 1.4.18 is the classic portable version. The 2.1 series of gnupg is not stable, it still has many major bugs, not the least of which is backwards compatibility with various key sizes previously supported (introduced by the new gpg to gpg-agent IPC layer restrictions). On the gnupg-devel mailing list I've seen a few potentially serious security issues with it. Given that it's not marked as stable upstream, and that it's such a critical core component of Arch's infrastructure, I find it questionable for Arch to have upgraded so soon. In the future, can we avoid upgrading gnupg proper to non-stable releases? Instead, how about creating a gpg21 or gpg-modern package would be appropriate for those wishing to try the unstable version and then updating the gnupg package once that branch gets marked stable?
Re: [arch-general] gnupg 2.1 not stable
On Wed, 17 Dec 2014 09:03:31 -0500, Ido Rosen wrote: Given that it's not marked as stable upstream, and that it's such a critical core component of Arch's infrastructure, I find it questionable for Arch to have upgraded so soon. Ido, thanks for the heads up :)! I considered Arch's core as something comparable to FreeBSD's world. The base system should be apart of the Arch's philosophy to follow upstream, even if upstream releases something as stable that is well known as completely broken as e.g. ... ok, I resist ... ;). Everything in core has to be as stable and as proved as possible. 2 Cents, Ralf
[arch-general] dhcpcd not working after install from custom iso
I had internet connection when installing from an iso I built using the archiso tools, but dhcpcd isn't connecting any more (starting via sytemd). I've also had internet access in previous installs of archlinux and FreeBSD, so I don't think there's anything wrong with the hardware. [dmesg output] http://pastebin.com/vtVRid1Y [ip link output] http://pastebin.com/gaZxUCmf The device I'm using is listed as enp2s0. It hangs, even though it's set up (pastebin for proof). Waiting for carrier? I also noticed that at the bottom of my dmesg, it reports only IPv6, not IPv4. Is this normal behavior? I think my network only supports IPv4, for dhcp anyway. Since I have to register the addresses of the NICs with the ISP, only enp2s0 should hypothetically be able to connect, not enp1s0. This is also the first time I've had a problem with dhcpcd. If it makes a difference, I built a custom iso (base) and dropped the bcache-tools package in /etc so I could set that up. I made no other modifications to the bulid. dhcpcd is at version 6.6.4-1 and is fully up-to-date. == LOG SNIPPET == dhcpcd@enp2s0.service - dhcpcd on enp2s0 Loaded: loaded (/usr/lib/systemd/system/dhcpcd@.service; disabled) Active: failed (Result: exit-code) since Wed 2014-12-17 09:15:46 EST; 51s ago Process: 542 ExecStart=/usr/bin/dhcpcd -q -w %I (code=exited, status=1/FAILURE) Dec 17 09:15:16 vss dhcpcd[542]: version 6.6.4 starting Dec 17 09:15:16 vss dhcpcd[542]: enp2s0: waiting for carrier Dec 17 09:15:46 vss systemd[1]: dhcpcd@enp2s0.service: control process exited, code=exited status=1 Dec 17 09:15:46 vss systemd[1]: Failed to start dhcpcd on enp2s0. Dec 17 09:15:46 vss systemd[1]: Unit dhcpcd@enp2s0.service entered failed state. Dec 17 09:15:46 vss systemd[1]: dhcpcd@enp2s0.service failed. -- vixsomnis
Re: [arch-general] gnupg 2.1 not stable
Ralf, On Wed, Dec 17, 2014 at 9:20 AM, Ralf Mardorf ralf.mard...@rocketmail.com wrote: On Wed, 17 Dec 2014 09:03:31 -0500, Ido Rosen wrote: Given that it's not marked as stable upstream, and that it's such a critical core component of Arch's infrastructure, I find it questionable for Arch to have upgraded so soon. Ido, thanks for the heads up :)! I considered Arch's core as something comparable to FreeBSD's world. The base system should be apart of the Arch's philosophy to follow upstream, even if upstream releases something as stable that is well known as completely broken as e.g. ... ok, I resist ... ;). Everything in core has to be as stable and as proved as possible. Agreed that everything in core should be maximally stable. (Also, following upstream stable releases rather than unstable releases fits just fine with Arch's philosophy of following upstream releases, since unstable releases are really just poorly named release candidates, which we don't usually follow.) Given that gpg is such a crucial core component of Arch's infrastructure and that gpg 2.1 is NOT stable. Could we switch back to gnupg 2.0.x (stable release) and create a gnupg-modern or gnupg21 package to track gnupg 2.1.x, which should be installable side-by-side with gnupg stable (perhaps with gpg21 as the binary name). 2 Cents, Ralf
Re: [arch-general] gnupg 2.1 not stable
On Wed, 17 Dec 2014 09:32:20 -0500, Ido Rosen wrote: Agreed that everything in core should be maximally stable. Given that gpg is such a crucial core component of Arch's infrastructure and that gpg 2.1 is NOT stable. Could we switch back to gnupg 2.0.x (stable release) GnuPG modern (2.1) is the brand new [snip] It will eventually ^^ replace the current stable (2.0) - https://www.gnupg.org/download/ ^^ IOW Ido isn't a troll. [root@archlinux rocketmouse]# downgrade gnupg Available packages: 1) gnupg-2.1.0-7-x86_64.pkg.tar.xz (local) 2) gnupg-2.1.0-6-x86_64.pkg.tar.xz (remote) 3) gnupg-2.1.0-4-x86_64.pkg.tar.xz (remote) 4) gnupg-2.0.26-1-x86_64.pkg.tar.xz (remote) 5) gnupg-2.0.25-1-x86_64.pkg.tar.xz (remote) 6) gnupg-2.0.23-1-x86_64.pkg.tar.xz (remote) 7) gnupg-2.0.22-2-x86_64.pkg.tar.xz (remote) select a package by number: 4 [snip] add gnupg to IgnorePkg? [y/n] y gnupg is security stuff, fellows, consider to care about it. I wasn't aware about this issue, so again, thank you Ido for the heads up :)! Regards, Ralf
Re: [arch-general] fdisk vs. gdisk for GPT partitioning
On Wed, Dec 17, 2014 at 02:30:43AM +0100, Neven Sajko wrote: On 16 December 2014 at 20:52, David J. Haines djhai...@gmx.com wrote: gdisk is also capable of placing new partitions at the end of a block of empty space without having to do manual calcuation of the start sector. I personally find this behavior invaluable. I'm curious why do you allocate partitions to the end of the disk. Do you want to be able to resize them more easily, or something else? For rotational media, you generally want to put your more-used data on the outside of the platters (the beginning of the disk from partitioning tools' perspective) because the data density of the platters is constant throughout, meaning that more data will pass under the heads in a given unit of time when they're at the outside of the platter, as opposed to the inside. Thus, you generally want to put things like /, /var, and /home on the outside (the beginning) and things like swap on the inside (the end), unless swapping happens to be what you want your system to really excel at. -- David J. Haines djhai...@gmx.com 0xAFB3D16D - F929 270F B7C3 78AE A741 434F A7C6 F264 AFB3 D16C
Re: [arch-general] LXDE on boot
I installed the arch distribution some time ago. I'm not sure of where I got the dist file from. My guess is Libreoffice was not installed and that may be why it wouldn't open when I clicked the Libreoffice icon. Last night I downloaded NOOBS and install AL. I will configure and install lxde and report any problems I have--Hopefully I'll have none. Thanks for your consideration and comment. John O.n Dec 17, 2014, at 3:29 AM, Johannes Altmanninger aclo...@gmail.com wrote: John Dey jsde...@gmail.com writes: Hi, I have installed openbox and lxde on a Raspberry Pi and configured to automatically start on boot. When I login (GUI), I get a blank screen with a cursor. Not the usual LXDE screen with panel at bottom. When I right click on mouse, I am given options--some of the applications will start such as xterm but others libreoffice don't. I don't know where the log files are? Is there anyone that can give me a helping hand. Thanks. John This may be the same bug as this one: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760971 So you probably have to copy a panel from /etc/xdg/lxpanel to ~/.config/lxpanel/LXDE/panels/ Are you sure you installed libreoffice? On Arch the openbox menu has some standard applications even if they are not installed.
Re: [arch-general] fdisk vs. gdisk for GPT partitioning
On December 17, 2014 10:04:43 AM EST, David J. Haines djhai...@gmx.com wrote: On Wed, Dec 17, 2014 at 02:30:43AM +0100, Neven Sajko wrote: On 16 December 2014 at 20:52, David J. Haines djhai...@gmx.com wrote: gdisk is also capable of placing new partitions at the end of a block of empty space without having to do manual calcuation of the start sector. I personally find this behavior invaluable. I'm curious why do you allocate partitions to the end of the disk. Do you want to be able to resize them more easily, or something else? For rotational media, you generally want to put your more-used data on the outside of the platters (the beginning of the disk from partitioning tools' perspective) because the data density of the platters is constant throughout, meaning that more data will pass under the heads in a given unit of time when they're at the outside of the platter, as opposed to the inside. Thus, you generally want to put things like /, /var, and /home on the outside (the beginning) and things like swap on the inside (the end), unless swapping happens to be what you want your system to really excel at. I've always been under the impression that hard drives start at the outer edge and work inward as they fill up, as opposed to optical disks. It makes the most logical sense, given the performance characteristics. -- vixsomnis
Re: [arch-general] fdisk vs. gdisk for GPT partitioning
On Wed, Dec 17, 2014 at 10:04 AM, David J. Haines djhai...@gmx.com wrote: On Wed, Dec 17, 2014 at 02:30:43AM +0100, Neven Sajko wrote: On 16 December 2014 at 20:52, David J. Haines djhai...@gmx.com wrote: gdisk is also capable of placing new partitions at the end of a block of empty space without having to do manual calcuation of the start sector. I personally find this behavior invaluable. I'm curious why do you allocate partitions to the end of the disk. Do you want to be able to resize them more easily, or something else? For rotational media, you generally want to put your more-used data on the outside of the platters (the beginning of the disk from partitioning tools' perspective) because the data density of the platters is constant throughout, meaning that more data will pass under the heads in a given unit of time when they're at the outside of the platter, as opposed to the inside. Thus, you generally want to put things like /, /var, and /home on the outside (the beginning) and things like swap on the inside (the end), unless swapping happens to be what you want your system to really excel at. I don't know if this is logic is still true with modern rotational disks (SMR/PMR/PCMR), or if it is as simple as beginning and end of block device translating to outer and inner platter sections -- I think there is some level of indirection. It does not diminish your argument for using gdisk, though. -- David J. Haines djhai...@gmx.com 0xAFB3D16D - F929 270F B7C3 78AE A741 434F A7C6 F264 AFB3 D16C
Re: [arch-general] gnupg 2.1 not stable
On 17/12/14 09:32, Ido Rosen wrote: Agreed that everything in core should be maximally stable. (Also, following upstream stable releases rather than unstable releases fits just fine with Arch's philosophy of following upstream releases, since unstable releases are really just poorly named release candidates, which we don't usually follow.) TBH, your argument is a red herring. Arch is about K.I.S.S. and following upstream as close to current as *upstream stable releases* allow. There have been occasions when what you propose has happened, mostly due to the chronic lack of developer hands and time. I can recall the headache it was to move from guile 1.8 to 2.x a little longer than a year ago. Given that gpg is such a crucial core component of Arch's infrastructure and that gpg 2.1 is NOT stable. Could we switch back to gnupg 2.0.x (stable release) and create a gnupg-modern or gnupg21 package to track gnupg 2.1.x, which should be installable side-by-side with gnupg stable (perhaps with gpg21 as the binary name). Instead, why not donate to gnupg.org so that the software is truly stable and evolves quickly? One underpaid (and underfed!) developer doesn't give any assurance about the future of the project and the software itself.[1] TL;DR: gnupg's situation is such that the OpenSSL project before the Heartbleed incident looks like a bunch of rich kids clubbing in Ibiza. [1] https://news.ycombinator.com/item?id=8761896 -- Pedro Alejandro López-Valencia http://about.me/palopezv/ Every nation gets the government it deserves. -- Joseph de Maistre
Re: [arch-general] gnupg 2.1 not stable
On Wed, Dec 17, 2014 at 11:00 AM, P. A. López-Valencia vorb...@outlook.com wrote: On 17/12/14 09:32, Ido Rosen wrote: Agreed that everything in core should be maximally stable. (Also, following upstream stable releases rather than unstable releases fits just fine with Arch's philosophy of following upstream releases, since unstable releases are really just poorly named release candidates, which we don't usually follow.) TBH, your argument is a red herring. Arch is about K.I.S.S. and following upstream as close to current as *upstream stable releases* allow. There have been occasions when what you propose has happened, mostly due to the chronic lack of developer hands and time. I can recall the headache it was to move from guile 1.8 to 2.x a little longer than a year ago. We seem to be in agreement: 2.1.x is not yet in the set of upstream *stable* releases, but 2.0.x is in that set. Therefore, Arch should follow 2.0.x until upstream has marked 2.1.x as stable. Someone made a mistake in upgrading to 2.1, so let's correct the mistake by downgrading back until it's safe, rather than leaving all of Arch's users at great security risk. Let's not forget that gnupg underlies all of Arch's security/integrity (i.e. pacman db and pkg signing) - it's how our users know that Arch is Alice-rch and not Eve-rch. IMO, downgrading is the responsible, smart (not stupid) thing to do, and let's not forget the last S in K.I.S.S... :-) Given that gpg is such a crucial core component of Arch's infrastructure and that gpg 2.1 is NOT stable. Could we switch back to gnupg 2.0.x (stable release) and create a gnupg-modern or gnupg21 package to track gnupg 2.1.x, which should be installable side-by-side with gnupg stable (perhaps with gpg21 as the binary name). Instead, why not donate to gnupg.org so that the software is truly stable and evolves quickly? One underpaid (and underfed!) developer doesn't give any assurance about the future of the project and the software itself.[1] TL;DR: gnupg's situation is such that the OpenSSL project before the Heartbleed incident looks like a bunch of rich kids clubbing in Ibiza. I donated, but I do not see your name on the donation list? [0] It can be in addition to, not instead. Also, your argument is a straw man: Upstream funding has nothing to do with whether Arch should follow what upstream has marked as a stable release vs. what upstream marked as unstable, not recommended for general use, feature development release; this is especially true of such a critical core component which underlies all of Arch's package distribution security/integrity (i.e. pacman-key). That one underpaid and underfed full time developer you refer to has marked 2.0 as stable and 2.1 as unstable, so upstream has not marked 2.1.x as stable yet. [0] https://www.gnupg.org/donate/kudos.html [1] https://news.ycombinator.com/item?id=8761896 -- Pedro Alejandro López-Valencia http://about.me/palopezv/ Every nation gets the government it deserves. -- Joseph de Maistre
[arch-general] community svntogit stuck
FYI, in case someone who maintains it looks at the mailing list, I must inform you that community svntogit web interface is stuck at the same commit for more than 24 hours now. https://projects.archlinux.org/svntogit/community.git/log/ -- Note: My last name is not Krejzi. signature.asc Description: OpenPGP digital signature
Re: [arch-general] community svntogit stuck
On 17 December 2014 at 16:39, Armin K. kre...@email.com wrote: FYI, in case someone who maintains it looks at the mailing list, I must inform you that community svntogit web interface is stuck at the same commit for more than 24 hours now. https://projects.archlinux.org/svntogit/community.git/log/ -- Note: My last name is not Krejzi. Looks okay here. Have you tried bypassing your browser's cache for that page? (Ctrl+F5 in some browsers) Cheers, WorMzy
Re: [arch-general] community svntogit stuck
On Wed, Dec 17, 2014 at 11:53 AM, WorMzy Tykashi wormzy.tyka...@gmail.com wrote: On 17 December 2014 at 16:39, Armin K. kre...@email.com wrote: FYI, in case someone who maintains it looks at the mailing list, I must inform you that community svntogit web interface is stuck at the same commit for more than 24 hours now. https://projects.archlinux.org/svntogit/community.git/log/ -- Note: My last name is not Krejzi. Looks okay here. Have you tried bypassing your browser's cache for that page? (Ctrl+F5 in some browsers) Are you just looking at the 33 min ago part? When you click into the latest commit that's marked 33 min ago on the log page Armin linked, you can see it is from 2014-12-10 16:56:41, so whatever stopped that page from updating happened about 33 minutes after that time, I think? When you click expand it shows more recent commits, so at least other parts of the site seem to be working... Cheers, WorMzy
Re: [arch-general] gnupg 2.1 not stable
besides the upstream stable release discussion (which i will leave out here) i have two small questions: On 12/17/2014 03:03 PM, Ido Rosen wrote: On the gnupg-devel mailing list I've seen a few potentially serious security issues with it. No offense, but out of interest: Could you please point them out with some references and links what exactly you consider potentially serious security issues on that mailing list? If its something that was not noticed to be potentially a serious security issue, did you raise awareness about that on the list or privately to the dev? On 12/17/2014 05:28 PM, Ido Rosen wrote: [...] Someone made a mistake in upgrading to 2.1, so let's correct the mistake by downgrading back until it's safe, rather than leaving all of Arch's users at great security risk. out of curiosity, what exactly and specifically do you consider a great security risk in 2.1. I would appreciate if you provide a concrete reference in 2.1 what you mean with great security risk. thanks in advice, cheers, Levente signature.asc Description: OpenPGP digital signature
Re: [arch-general] community svntogit stuck
On 17 December 2014 at 17:03, Ido Rosen i...@kernel.org wrote: On Wed, Dec 17, 2014 at 11:53 AM, WorMzy Tykashi wormzy.tyka...@gmail.com wrote: On 17 December 2014 at 16:39, Armin K. kre...@email.com wrote: FYI, in case someone who maintains it looks at the mailing list, I must inform you that community svntogit web interface is stuck at the same commit for more than 24 hours now. https://projects.archlinux.org/svntogit/community.git/log/ -- Note: My last name is not Krejzi. Looks okay here. Have you tried bypassing your browser's cache for that page? (Ctrl+F5 in some browsers) Are you just looking at the 33 min ago part? When you click into I was, whoops. I can see the problem now too. Sorry for the noise. the latest commit that's marked 33 min ago on the log page Armin linked, you can see it is from 2014-12-10 16:56:41, so whatever stopped that page from updating happened about 33 minutes after that time, I think? When you click expand it shows more recent commits, so at least other parts of the site seem to be working... Cheers, WorMzy
Re: [arch-general] gnupg 2.1 not stable
On 17/12/14 11:28, Ido Rosen wrote: We seem to be in agreement: 2.1.x is not yet in the set of upstream *stable* releases, but 2.0.x is in that set. Not really. You missed the as close to current. Therefore, Arch should follow 2.0.x until upstream has marked 2.1.x as stable. Someone made a mistake in upgrading to 2.1, so let's correct the mistake by downgrading back until it's safe, rather than leaving all of Arch's users at great security risk. Let's not forget that gnupg underlies all of Arch's security/integrity (i.e. pacman db and pkg signing) - it's how our users know that Arch is Alice-rch and not Eve-rch. IMO, downgrading is the responsible, smart (not stupid) thing to do, and let's not forget the last S in K.I.S.S... :-) The usual practice is to wait until there is a first point release that catches the most glaring bugs, see for example how the kernel and the main desktop environments are updated. The first point release was yesterday (2014-12-16) and it is already in testing. This transition would have occurred sooner or later because the benefits outweigh the cost of moving to the newer version---e,g., the ability to use elliptical curve keys---, but it would've been reasonable to wait for this first point release. I donated, but I do not see your name on the donation list? [0] Do not stoop to personal attacks. Thank you. Besides that, I never make public my acts of charity. Have you read Matthew 6:3? Even good atheists practice it. -- Pedro Alejandro López-Valencia http://about.me/palopezv/ Every nation gets the government it deserves. -- Joseph de Maistre
Re: [arch-general] gnupg 2.1 not stable
On Wed, Dec 17, 2014 at 12:41 PM, P. A. López-Valencia vorb...@outlook.com wrote: On 17/12/14 11:28, Ido Rosen wrote: We seem to be in agreement: 2.1.x is not yet in the set of upstream *stable* releases, but 2.0.x is in that set. Not really. You missed the as close to current. I didn't miss the as close to current. You said as close to current as *upstream stable releases* allow. 2.1.x is not an upstream stable release while 2.0.x is, therefore we are closer to current than upstream stable releases allow. So, as I said, we are in agreement, and IMO a mistake was made and should be rectified by a downgrade rather than leaving Arch users at risk of security breaches. Therefore, Arch should follow 2.0.x until upstream has marked 2.1.x as stable. Someone made a mistake in upgrading to 2.1, so let's correct the mistake by downgrading back until it's safe, rather than leaving all of Arch's users at great security risk. Let's not forget that gnupg underlies all of Arch's security/integrity (i.e. pacman db and pkg signing) - it's how our users know that Arch is Alice-rch and not Eve-rch. IMO, downgrading is the responsible, smart (not stupid) thing to do, and let's not forget the last S in K.I.S.S... :-) The usual practice is to wait until there is a first point release that catches the most glaring bugs, see for example how the kernel and the main desktop environments are updated. The first point release was yesterday (2014-12-16) and it is already in testing. This transition would have occurred sooner or later because the benefits outweigh the cost of moving to the newer version---e,g., the ability to use elliptical curve keys---, but it would've been reasonable to wait for this first point release. I donated, but I do not see your name on the donation list? [0] Do not stoop to personal attacks. Thank you. Besides that, I never make public my acts of charity. Have you read Matthew 6:3? Even good atheists practice it. It was not a personal attack. You encouraged me to donate, so I did, and was encouraging you to practice what you preach (i.e. to donate as well). I'm not Christian, but I think that's covered later on in Matthew 7:2...? Did you read the rest of that paragraph? You disregarded my points as a red herring, then made a straw man argument that we should donate instead of downgrading (and leave Arch users vulnerable). In the same paragraph, you quote Arch policy which agrees with the downgrade... I guess you are just trolling. Happy holidays, either way. :-) -- Pedro Alejandro López-Valencia http://about.me/palopezv/ Every nation gets the government it deserves. -- Joseph de Maistre
Re: [arch-general] gnupg 2.1 not stable
The usual practice is to wait until there is a first point release that catches the most glaring bugs, see for example how the kernel and the main desktop environments are updated. The first point release was yesterday (2014-12-16) and it is already in testing. This transition would have occurred sooner or later because the benefits outweigh the cost of moving to the newer version---e,g., the ability to use elliptical curve keys---, but it would've been reasonable to wait for this first point release. Also I wanted to address your last sentence re the 2.1.1 point release since it is in general good advice, but not a good idea in this case unfortunately: In the release email for gnupg 2.1.1 it says it is not fit for general use and is not a stable release (latest development). **We should not upgrade to this point release, instead we should downgrade to 2.0.x.** http://lists.gnupg.org/pipermail/gnupg-announce/2014q4/000360.html [...] Three different versions of GnuPG are actively maintained: - GnuPG modern (2.1) is the latest development with a lot of new features. This announcement is about the first release of this version. - GnuPG stable (2.0) is the current stable version for general use. This is what most users are currently using. - GnuPG classic (1.4) is the old standalone version which is most suitable for older or embedded platforms. You may not install modern (2.1) and stable (2.0) at the same time. However, it is possible to install classic (1.4) along with any of the other versions. [...]
Re: [arch-general] gnupg 2.1 not stable
On Wed, Dec 17, 2014 at 12:05 PM, Levente Polyak anthr...@archlinux.org wrote: besides the upstream stable release discussion (which i will leave out here) i have two small questions: On 12/17/2014 03:03 PM, Ido Rosen wrote: On the gnupg-devel mailing list I've seen a few potentially serious security issues with it. No offense, but out of interest: No offense taken at all, these are good questions to ask. Could you please point them out with some references and links what exactly you consider potentially serious security issues on that mailing list? If its something that was not noticed to be potentially a serious security issue, did you raise awareness about that on the list or privately to the dev? Several security patches went into 2.1 after its release, and there continue to be patches submitted for minor issues that are borderline security/usability issues in the bug fix category. Most of those bugs at worst result in DoSes, but two of them in particular could result in invalid signature verification output. The 2.1.x codebase is still under relatively heavy active development (in code coverage terms) and new features seem to be going into it with every point release. This is my interpretation from following the gnupg-devel mailing list and having some familiarity with how gnupg releases have come out in the past. (Werner Koch does an excellent job of making the releases as secure as he can, but I think he has a good security reason why 2.1 isn't marked as ready for general use or stable yet. I trust him to mark 2.1 stable when he thinks it is ready for public consumption.) On 12/17/2014 05:28 PM, Ido Rosen wrote: [...] Someone made a mistake in upgrading to 2.1, so let's correct the mistake by downgrading back until it's safe, rather than leaving all of Arch's users at great security risk. out of curiosity, what exactly and specifically do you consider a great security risk in 2.1. I would appreciate if you provide a concrete reference in 2.1 what you mean with great security risk. The great security risk is in reference to the fact that Arch uses gnupg to validate package repository authenticity and package authenticity, as well as other places. In practice, I see several security patches went into 2.1 after 2.1.0 was released, including some to fix bugs that only affected 2.1.0 and not 2.0.x. Some of those bugs are immediately exploitable, but it would be irresponsible to disclose which publicly (and I'm not a security researcher). For me, the bigger issue is that the developers themselves do not consider 2.1 ready for general use, and that it's the only thing preventing an Arch mirror compromise from turning into an Arch compromise. thanks in advice, cheers, Levente
Re: [arch-general] gnupg 2.1 not stable
Also, since it was mentioned regarding 2.1.x: ECC support is nice to have, but is a new feature that's not required for Arch db/package verification. That's why I suggested that we downgrade gnupg to 2.0.x and, for those users who are willing to take the risk with gnupg 2.1.x before it is marked stable, we can create a gnupg21 package (perhaps in AUR?), and then once gnupg 2.1 is marked as stable, we can rename gnupg21 to gnupg and add conflicts= and replaces= as appropriate... Gaetan, since you maintain gnupg, your word is law, so what are your thoughts?
Re: [arch-general] gnupg 2.1 not stable
On 17/12/14 13:04, Ido Rosen wrote: Did you read the rest of that paragraph? You disregarded my points as a red herring, then made a straw man argument that we should donate instead of downgrading (and leave Arch users vulnerable). In the same paragraph, you quote Arch policy which agrees with the downgrade... I guess you are just trolling. Happy holidays, either way. :-) I did read the rest of the paragraph but considered it not relevant to the discussion. The donation was not a strawman argument but rather a statement of fact about the actual situation with the gnupg.org project and its higher relevance to your concerns about security of the software. I did use the opportunity to try and have the discussion go outside the box and not focus completely on your arguments, which as presented might cause panic in some users. I do understand your concerns about stability but, honestly, using Arch is a guarantee to be bitten sooner or later. Also, I agree that gnupg would have been better kept at 2.0.x for sometime and have 2.1.x in community or AUR even for at least 2 or 3 point releases. But considering the changes in keyring management and the higher security (like disabling all pgp keys with md5 hashes), I can live with the changes. Those same changes make downgrading a painful process. Addressing your observations in the follow up message to the one I'm responding to, notice that nowhere in the release message says that you must not use gpg modern, only that gpg stable is what most users use and perhaps the one with less bugs. As Arch uses current software in most cases, we the users are QA testers for more upstream projects that we can believe, so I wasn't surprised by the move to gnupg, but see above. Happy Holidays to you too. :-) -- Pedro Alejandro López-Valencia http://about.me/palopezv/ Every nation gets the government it deserves. -- Joseph de Maistre
Re: [arch-general] gnupg 2.1 not stable
On Wed, Dec 17, 2014 at 1:46 PM, P. A. López-Valencia vorb...@outlook.com wrote: On 17/12/14 13:04, Ido Rosen wrote: Did you read the rest of that paragraph? You disregarded my points as a red herring, then made a straw man argument that we should donate instead of downgrading (and leave Arch users vulnerable). In the same paragraph, you quote Arch policy which agrees with the downgrade... I guess you are just trolling. Happy holidays, either way. :-) I did read the rest of the paragraph but considered it not relevant to the discussion. The donation was not a strawman argument but rather a statement of fact about the actual situation with the gnupg.org project and its higher relevance to your concerns about security of the software. I did use the opportunity to try and have the discussion go outside the box and not focus completely on your arguments, which as presented might cause panic in some users. I do understand your concerns about stability but, honestly, using Arch is a guarantee to be bitten sooner or later. Your comment about stability in Arch is yet another straw man. I'm concerned about continuity and security against distribution channel being hijacked: Arch has no continuity if it can't reliably verify the authenticity of its distribution channel (i.e. if database and package signatures stop working properly, or someone compromised them). If it were any other piece of Arch, like libc or even the kernel, I wouldn't care as much, but this is the piece of Arch that is responsible for telling an Arch user that he is really getting Arch and not some backdoored malicious lookalike. The correct response is indeed for users to panic and demand that Arch devs be more responsible about reading release notes before upgrading such important core components of the system. Also, I agree that gnupg would have been better kept at 2.0.x for sometime and have 2.1.x in community or AUR even for at least 2 or 3 point releases. But considering the changes in keyring management and the higher security (like disabling all pgp keys with md5 hashes), I can live with the changes. Those same changes make downgrading a painful process. As for downgrading being painful: I just downgraded that way and it was painless (and pacman, all pacman keys, keyring, etc. still work for me). Addressing your observations in the follow up message to the one I'm responding to, notice that nowhere in the release message says that you must not use gpg modern, only that gpg stable is what most users use and perhaps the one with less bugs. As Arch uses current software in most cases, we the users are QA testers for more upstream projects that we can believe, so I wasn't surprised by the move to gnupg, but see above. This is what the 2.1.1 point release says, verbatim: - GnuPG modern (2.1) is the latest development with a lot of new features. This announcement is about the first release of this version. - GnuPG stable (2.0) is the current stable version for general use. This is what most users are currently using. So, it does directly imply that you should not use gpg modern (not stable) yet for general use, as opposed to development. It goes as far as calling modern a development release, and to draw the distinction between it and the stable release. It also implies that modern is not yet suited for general use, by saying that stable is for general use.Whether or not we parse these words verbatim or add some interpretation, the meaning is clear: 2.0 is for general use and is stable, 2.1.1 is not stable and is a development release.
Re: [arch-general] dhcpcd not working after install from custom iso
On 17/12/14 09:22, Christian Demsar wrote: I had internet connection when installing from an iso I built using the archiso tools, but dhcpcd isn't connecting any more (starting via sytemd). I've also had internet access in previous installs of archlinux and FreeBSD, so I don't think there's anything wrong with the hardware. [dmesg output] http://pastebin.com/vtVRid1Y [ip link output] http://pastebin.com/gaZxUCmf You say you configured your connection with systemd. Do you mean you enabled dhcpd@enp2s0.service? I suggest you disable it and use systemd-networkd instead. It is very simple. Create a file called /etc/systemd/network/enp2s0.network that contains: [Match] Name=enp2s0 [Network] DHCP=v4 Enable and start systemd-networkd.service and reboot. Your link should come up online. -- Pedro Alejandro López-Valencia https://about.me/palopezv
Re: [arch-general] gnupg 2.1 not stable
[2014-12-17 09:03:31 -0500] Ido Rosen: 2.0.26 is the stable version suggested for most users, 2.1.1 is the brand-new modern version Arch is not stable, it's modern. Besides, there are no open bugs regarding gnupg on our tracker. -- Gaetan
Re: [arch-general] gnupg 2.1 not stable
On 12/17/2014 07:32 PM, Ido Rosen wrote: Several security patches went into 2.1 after its release, and there continue to be patches submitted for minor issues that are borderline security/usability issues in the bug fix category. Most of those bugs at worst result in DoSes, but two of them in particular could result in invalid signature verification output. The 2.1.x codebase is still under relatively heavy active development (in code coverage terms) and new features seem to be going into it with every point release. This is my interpretation from following the gnupg-devel mailing list and having some familiarity with how gnupg releases have come out in the past. thanks for the explanation, but you misunderstood my question: can you please provide references in form of links or commit hashes that are pointing to those, because thats actually what i asked for. For what i currently see there is nothing that needs should mark this explicitly as highly unsecure and potentially a serious security issue because if we can't point at specific things, then this statement can be applied to probably any software that is under development. Don't get me wrong, i totally get your point and roughly looked up the tree, but i asked for specific references that back those statements up. Its just hardly overreacted to speak about potentially a serious security issue in general. (Werner Koch does an excellent job of making the releases as secure as he can, but I think he has a good security reason why 2.1 isn't marked as ready for general use or stable yet. I trust him to mark 2.1 stable when he thinks it is ready for public consumption.) So it's only your assumption that he has good security reason to hold that back? Can you proof that he did such a security concerns related statement please? I still get your point, but please back up your statements with links and references, thats all i ask for. On 12/17/2014 05:28 PM, Ido Rosen wrote: [...] Someone made a mistake in upgrading to 2.1, so let's correct the mistake by downgrading back until it's safe, rather than leaving all of Arch's users at great security risk. out of curiosity, what exactly and specifically do you consider a great security risk in 2.1. I would appreciate if you provide a concrete reference in 2.1 what you mean with great security risk. The great security risk is in reference to the fact that Arch uses gnupg to validate package repository authenticity and package authenticity, as well as other places. In practice, I see several security patches went into 2.1 after 2.1.0 was released, including some to fix bugs that only affected 2.1.0 and not 2.0.x. Some of those bugs are immediately exploitable, but it would be irresponsible to disclose which publicly (and I'm not a security researcher). Yep I agree that it is a critical part of the infrastructure, but there are also problems which do appear in stable versions. As an example there is CVE-2014-4617 [0] affecting 2.0 and sometimes you also have to deal with libs that are not your own code-base but make you vulnerable, like libksba CVE-2014-9087 [1]. I asked for very specific references because if you want that things get fixed, you should point out specific problems so they can be issued and mitigated in our packages. In cause of libksba CVE-2014-9087 [1] the specific problem got tracked and mitigated as fast as possible and interested users got notified [2]. those bugs are immediately exploitable, but it would be irresponsible to disclose which publicly If that is true, you should contact someone and point out the issues in a private conversation so a specific problem can be backported and mitigated for Archlinux. You can also contact secur...@archlinux.org in such situation or coordinate a responsible disclosure/mitigation with MITRE [3] if you spotted a serious issue which no one is aware of. To be honest, it is explicitly *irresponsible* if you just keep that secret for yourself because its not only security through obscurity but you may also held something vulnerable which we could mitigate. Especially related to this particular situation with GnuPG i would call it controversial, because you raised the security concern topic for GnuPG 2.1 (which we are in fact currently using) and on the other side you are speaking about those bugs are immediately exploitable, which means that you are holding back information that may affect people *right now*. If you are really interested in reducing the current security concerns, please follow one of the above recommended ways to raise awareness about a specific issue. Right now we already have gnupg 2.1.1-1 in testing that fixes several bugs since 2.1.0-7, but from the git logs [4] or bugtracker [5] i currently can't spot something that could potentially compromise a mirror. To be clear: I have asked for specific and explicit issues to be able to push mitigation and track it. To do so I need clear references,
Re: [arch-general] gnupg 2.1 not stable
On Thu, 18 Dec 2014 07:43:52 +1100 Gaetan Bisson bis...@archlinux.org wrote: [2014-12-17 09:03:31 -0500] Ido Rosen: 2.0.26 is the stable version suggested for most users, 2.1.1 is the brand-new modern version Arch is not stable, it's modern. Besides, there are no open bugs regarding gnupg on our tracker. https://bugs.archlinux.org/task/42972 ~Jacob pgpfSBpVTl1C9.pgp Description: OpenPGP digital signature
Re: [arch-general] dhcpcd not working after install from custom iso
Hi On Wed, Dec 17, 2014 at 10:22 PM, Christian Demsar vixsom...@fastmail.com wrote: I had internet connection when installing from an iso I built using the archiso tools, but dhcpcd isn't connecting any more (starting via sytemd). I've also had internet access in previous installs of archlinux and FreeBSD, so I don't think there's anything wrong with the hardware. [dmesg output] http://pastebin.com/vtVRid1Y [ip link output] http://pastebin.com/gaZxUCmf The device I'm using is listed as enp2s0. It hangs, even though it's set up (pastebin for proof). Waiting for carrier? I also noticed that at the bottom of my dmesg, it reports only IPv6, not IPv4. Is this normal behavior? I think my network only supports IPv4, for dhcp anyway. Since I have to register the addresses of the NICs with the ISP, only enp2s0 should hypothetically be able to connect, not enp1s0. This is also the first time I've had a problem with dhcpcd. If it makes a difference, I built a custom iso (base) and dropped the bcache-tools package in /etc so I could set that up. I made no other modifications to the bulid. dhcpcd is at version 6.6.4-1 and is fully up-to-date. == LOG SNIPPET == dhcpcd@enp2s0.service - dhcpcd on enp2s0 Loaded: loaded (/usr/lib/systemd/system/dhcpcd@.service; disabled) Active: failed (Result: exit-code) since Wed 2014-12-17 09:15:46 EST; 51s ago Process: 542 ExecStart=/usr/bin/dhcpcd -q -w %I (code=exited, status=1/FAILURE) This log does not provide enough information information about the failure. Run dhcpcd manually with debug enabled sudo dhcpcd -q -w enp2s0 -d And you'll have better luck to debug this problem by sending your questions upstream maillist. Dec 17 09:15:16 vss dhcpcd[542]: version 6.6.4 starting Dec 17 09:15:16 vss dhcpcd[542]: enp2s0: waiting for carrier Dec 17 09:15:46 vss systemd[1]: dhcpcd@enp2s0.service: control process exited, code=exited status=1 Dec 17 09:15:46 vss systemd[1]: Failed to start dhcpcd on enp2s0. Dec 17 09:15:46 vss systemd[1]: Unit dhcpcd@enp2s0.service entered failed state. Dec 17 09:15:46 vss systemd[1]: dhcpcd@enp2s0.service failed. -- vixsomnis
Re: [arch-general] gnupg 2.1 not stable
On Wed, 17 Dec 2014 14:19:09 -0500 Ido Rosen i...@kernel.org wrote: The correct response is indeed for users to panic and demand that Arch devs be more responsible about reading release notes before upgrading such important core components of the system. LOL, are you serious? Do you know how long Arch operated without package signing? You now expect users to panic? You're taking this way, way to far.
Re: [arch-general] gnupg 2.1 not stable
Doug Newgard wrote: LOL, are you serious? Do you know how long Arch operated without package signing? You now expect users to panic? That's actually why I didn't run Arch before despite liking a lot of the philosophy. The big sticking point. The only real reason. Fortunately, now that I _know_ about this, due to the surrounding philosophy of simple composability and user-centric control, it may become possible for me to tweak my systems like earlier in the thread if I decide the main packagers are playing too fast and loose with GnuPG versioning. The upstream release cycle seems a bit unclear and does not play particularly cleanly with the notion of rolling-release Linux software distribution; the wording on the website doesn't distinguish well how comparatively stable the modern branch can be expected to be. I do certainly think GnuPG is a special case and should be more carefully integrated, even if it requires bending the general principle of avoiding lagging upstream. It's not clear to me whether falling back to the stable GnuPG is a good way to do this. I think _if_ modern can be demonstrated to be a /de facto/ development branch right now then it should be relegated to a more-experimental package, but there's potential follow-on problems surrounding how many users test the rest of the system with a newer GnuPG. Has upstream actually been contacted about this to ask what they think? --- Drake Wilson
Re: [arch-general] gnupg 2.1 not stable
On Wed, 17 Dec 2014 21:32:26 -0600 Drake Wilson dr...@dasyatidae.net wrote: Doug Newgard wrote: LOL, are you serious? Do you know how long Arch operated without package signing? You now expect users to panic? That's actually why I didn't run Arch before despite liking a lot of the philosophy. The big sticking point. The only real reason. That's fine, but we haven't gone back to the days of no signing. This entire thread is about the possibility that a vulnerability *could* exist. Not that one does, but that there's some possibility that it could happen. Blowing this way out of proportion. To suggest that users panic because of the possibility of an unknown vulnerability seems ludicrous.
