Re: [arch-general] Heads up: If you are using SSLv2 turn it off immediately
On jue, 2016-03-03 at 08:37 +0100, Nicolas F. wrote: > On 01/03/16 23:23, P. A. López-Valencia wrote: > > > > The vulnerability is so bad[1], it doesn't only have a CVE number, > > CVE-2016-0800[4], but a name and its own website: HTTPS > > DROWN[1][2][3]. > Just as many other vulnerabilities these days, there is a marketing > campaign behind them, probably to sell consultancy services. > > Anybody who's security-minded hasn't been using SSLv2 anyway. > > In a perfect world, yes. But your assumption is not realistic. Not everyone is following the latest news on infosec and it is not that easy to disable on the server side. A reminder is always in order. -- Pedro A. López-Valencia http://about.me/palopezv Recession is when your neighbor loses his job. Depression is when you lose yours. -Ronald Reagan
[arch-general] Heads up: If you are using SSLv2 turn it off immediately
If you are have a web server facing the public internet, turn off SSLv2 immediately. OpenSSL 1.0.2g has the fix but it will take a while to drip down to the repos as it brings with it an ABI change. The vulnerability is so bad[1], it doesn't only have a CVE number, CVE-2016-0800[4], but a name and its own website: HTTPS DROWN[1][2][3]. One third of all public web servers are open to attack[2][3] and OpenSSL may not be the only crypto library affected[1][4]. [1] http://www.theregister.co.uk/2016/03/01/drown_tls_protocol_flaw/ [2] http://www.theregister.co.uk/2016/03/01/drown_crypto_flaw_analysis/ [3] https://drownattack.com/#paper [4] https://access.redhat.com/security/cve/cve-2016-0800 -- Pedro A. López-Valencia http://about.me/palopezv/ Recession is when a neighbor loses his job. Depression is when you lose yours. -Ronald Reagan
Re: [arch-general] Boot SuperMicro H8QM8-2 w/4 Opteron 8360 - hangs on boot of install media
El 29/02/2016 a las 6:44 p. m., David C. Rankin escribió: > All, > >This may be a stupid question. If so I apologize. Do I have to do anything > different to boot the arch install media on a board with 4 Opteron 8360 > processors (16 core total), or should the kernel just handle however many > cores > there are? > There is no problem there. Arch's default kernel configuration supports up to and including 32 cores. >The reason I ask is it always hangs after it says Booting Kernel > (immediately > after decompress). When I memtest the memory, (I have two sets and I've gone > stick by stick with a minimum memory config, and I still get errors at the > exact > same percentage of every test.) I have rotated each stick in/out with a > replacement, and replaced the whole set, but same issue. If you are sure the RAM sticks are working fine by, say, burning them in a different rig, then you may have a problem with the memory controller. or something more insidious in the firmware controller. In any case, it sounds to me you need to RMI the box. I've heard SuperMicro has above average tech support... [snip] >What say the experts? Do I need to pass a kernel flag, or something similar > for the 4 Opteron boot, or does it just smell like multiple failed sticks in > each set? > I've never had problems with AMD-based servers. But the usual stuff in these parts is HP (now HPE), what used to be IBM (don't recall which Chinese outfit scavenged that part of the business), Dell and MSI-based white boxes. -- Pedro A. López-Valencia http://about.me/palopezv/ Recession is when a neighbor loses his job. Depression is when you lose yours. -Ronald Reagan
Re: [arch-general] Mutt - no authenticators available
On jue, 2016-02-25 at 14:25 -0500, P. A. López-Valencia wrote: > > Outlook.com supports SSL for IMAP and TLS for SMTP on the receive > port > (567). Make that port 587. -- Pedro A. López-Valencia http://about.me/palopezv Recession is when your neighbor loses his job. Depression is when you lose yours. -Ronald Reagan
Re: [arch-general] Mutt - no authenticators available
On jue, 2016-02-25 at 11:18 +0800, Fulcrum wrote: > You don't need this: > set imap_authenticators=”gssapi:digest-md5:cram-md5:login” > set smtp_authenticators=”gssapi:digest-md5:cram-md5:login” You should always use SSL and TLS to connect to an email providerm by the way. If it doesn't support SSL/TLS, well you should run away faster from it than from the black plague and taxmen. Outlook.com supports SSL for IMAP and TLS for SMTP on the receive port (567). And that brings me to point out: When you use a trustworthy SSL or TLS connection, you don't need password authentication thingamagicks. You use PLAIN auth. Outlook.com (and Gmail, Yahoo!, GMX and others) only support PLAIN auth over SSL or TLS. > > I tried using a gmail account; didnt work. I hope someone here could > help me. A Gmail account will require OAUTH2 support in the client by default, ---the reason why you can connect with thunderbird, and using POP3 of all things (yuck!) as you pointed out later in this thread that IMAP support was disabled---. You can enable password authentication in the security section at https://myaccount.google.com/ not before being admonished that doing so will probably rob your youth, hair and fortune. On how go about finding out the right parameters to configure mutt with your Outlook.com account (bear with me, hotmail.com is dead and your address is just an alias to an Outlook.com inbox), configure the account in thunderbird as an IMAP account and the review the configuration generated for the account. SMTP settings are at the end of the account settings list in thunderbird. > Regards, > Fulcrum -- Pedro A. López-Valencia http://about.me/palopezv Recession is when your neighbor loses his job. Depression is when you lose yours. -Ronald Reagan
Re: [arch-general] Vulkan packages
El 14/02/2016 a las 10:45 p. m., Eric Engeström escribió: > Hi all, > > With the release of Vulkan imminent, I thought I'd prepare some packages > for Arch so that I can push them the minute it gets released :) > > I was thinking of splitting it into 4 packages: > - `vulkan-loader` with everything you need to run an app compiled against > Vulkan (/usr/lib/libvulkan.so*). This is what Vulkan-apps packages would > `depend` on. > - `vulkan-headers` with everything you need to build an app for Vulkan > (/usr/include/vulkan/* & /usr/lib/pkgconfig/vulkan.pc) (depends on > `-loader`) > - `vulkan-sdk` with all the debugging and validation stuff from LunarG > (/usr/bin/*, /usr/share/vulkan/*) (depends on `-headers` + `-loader`) > - `vulkan-manpages` (self-explanatory :P) > I've also made `-git` versions of all of those, except the `-sdk`: I can't > make it clean enough for a PKGBUILD without heavy patching of upstream's > build scripts (I'm hoping somebody fixes that soon enough, I don't have the > patience to do it myself :P). > > Does this sound reasonable? Supporting the minimal approach, have you examined boost packaging and naming? boost-libs contains the runtime libraries and the boost package what you would call the SDK, namely all the header, pkgconfig files and whatnot. -- Pedro A. López-Valencia http://about.me/palopezv/ Recession is when a neighbor loses his job. Depression is when you lose yours. -Ronald Reagan
Re: [arch-general] Error message with full disk encryption
El 14/02/2016 a las 1:49 p. m., Carsten Mattner escribió: > On Sun, Feb 14, 2016 at 5:23 PM, PeLo L wrote: >> adding 'shutdown' hook doesn't seem to work. Modifying '/etc/fstab' >> and replacing the UUID with '/dev/mapper/crypt-boot' did the trick. > I've never used UUID volume id and still see the bug. That's truly weird. I like a good murder mystery so I'll be doing some on-hands experimentation and report a bug if needed. -- Pedro A. López-Valencia http://about.me/palopezv/ Recession is when a neighbor loses his job. Depression is when you lose yours. -Ronald Reagan
Re: [arch-general] Error message with full disk encryption
El 13/02/2016 a las 6:44 p. m., P. A. López-Valencia escribió: > > Well, it doesn't happen to me unless I add the hook. Probably it was > true three years ago, but it got broken along the way. I customarily > replace the udev hook with the systemd hook and not even then is the > initramfs copy created on /run/initramfs unless I add the sd-shutdown > hook. Or keep the udev hook and add the shutdown hook. Both work for me. :-) > I correct myself. I was under the impression that the sd-systemd hook worked but it doesn't. Stick to the old udev and shutdown hooks. -- Pedro A. López-Valencia http://about.me/palopezv/ Recession is when a neighbor loses his job. Depression is when you lose yours. -Ronald Reagan
Re: [arch-general] Error message with full disk encryption
El 13/02/2016 a las 6:28 p. m., Merlin Büge escribió: > Hi, > > I thought this was obsolete since mkinitcpio 16? See > https://lists.archlinux.org/pipermail/arch-dev-public/2013-December/025742.html > > (I'm not sure, just curious...) @OP: I had a similar issue a few > months ago and fixed it, see second post of this: > https://bbs.archlinux.org/viewtopic.php?id=205275 (But I still haven't > understood *why* that fixed it...) Best Regards, mearon Well, it doesn't happen to me unless I add the hook. Probably it was true three years ago, but it got broken along the way. I customarily replace the udev hook with the systemd hook and not even then is the initramfs copy created on /run/initramfs unless I add the sd-shutdown hook. Or keep the udev hook and add the shutdown hook. Both work for me. :-) -- Pedro A. López-Valencia http://about.me/palopezv/ Recession is when a neighbor loses his job. Depression is when you lose yours. -Ronald Reagan
Re: [arch-general] Error message with full disk encryption
El 13/02/2016 a las 4:49 a. m., PeLo L escribió: > Hi, > > > I've followed the arch wiki and deployed a full disk encrypted install. > Everything works fine and am able to boot properly into the install. While > trying to shutdown my system, systemd displays an error which says "systemd: > stopped (with error) /dev/mapper/crypt-boot". 'crypt-boot' is the device > mapper name for the encrypted boot partition. Could someone explain this. Do > I need to be concerned of any data loss in the boot partition? > > > - Solomon > As you are shutting down, the filesystem becomes unreadable for the systemd process, you need to add the shutdown hook to mkinitcpio in order to have a copy of the initramfs at shutdown time. -- Pedro A. López-Valencia http://about.me/palopezv/ Recession is when a neighbor loses his job. Depression is when you lose yours. -Ronald Reagan
Re: [arch-general] Missing fonts in KeePass
On 24/12/14 09:15, Sadika Sumanapala wrote: > Ahh. Yes, that will happen because chromium based browsers use an internal (and older) fontconfig. A shame really. The other alternative is to replace the files: > 30-metric-aliases.conf > 45-latin.conf > 60-latin.conf > in /etc/fonts/conf.avail with copies from fontconfig's git repo trunk. I'm attaching them here too. I tried with the attached files but it did not resolve the issue. After that I tried those files with previous 3 methods but no luck. Anyway thank you for your help Now that's strange. It works here. I don't use ttf-ms-fonts nor ttf-liberation in this system, rather I use a set of OTF versions of the gsfonts I converted myself with AFDKO and those configuration files. You also mentioned previously that using ttf-ms-fonts did not fix the issue either. This is a bug that you should report upstream. Happy Holidays. -- Pedro Alejandro López-Valencia http://about.me/palopezv/
Re: [arch-general] Missing fonts in KeePass
On 22/12/14 11:09, Sadika Sumanapala wrote: A.) Installing fontconfig-git from the AUR. B.) Install ttf-ms-fonts as already mentioned in this thread. C.) Do both. And while at it install ttf-carlito and ttf-caladea to replace Calibri and Cambria in all those Office 2007/2010/2013 documents out there. First I'm extremely sorry for taking long time to reply. I've tried all three methods but no success. After I install fontconfig-git all the fonts on chromium browsers tabs and address bar changes to some kind of dots. Ahh. Yes, that will happen because chromium based browsers use an internal (and older) fontconfig. A shame really. The other alternative is to replace the files: 30-metric-aliases.conf 45-latin.conf 60-latin.conf in /etc/fonts/conf.avail with copies from fontconfig's git repo trunk. I'm attaching them here too. -- Pedro Alejandro López-Valencia http://about.me/palopezv/ Nimbus Sans L Helvetica Nimbus Sans Helvetica TeX Gyre Heros Helvetica Nimbus Sans Narrow Helvetica Condensed TeX Gyre Heros Cn Helvetica Condensed Nimbus Roman No9 L Times Nimbus Roman Times TeX Gyre Termes Times Nimbus Mono L Courier Nimbus Mono Courier TeX Gyre Cursor Courier Avant Garde ITC Avant Garde Gothic URW Gothic L ITC Avant Garde Gothic URW Gothic ITC Avant Garde Gothic TeX Gyre Adventor ITC Avant Garde Gothic Bookman ITC Bookman URW Bookman L ITC Bookman Bookman URW ITC Bookman TeX Gyre Bonum ITC Bookman Bookman Old Style ITC Bookman Zapf Chancery ITC Zapf Chancery URW Chancery L ITC Zapf Chancery Chancery URW ITC Zapf Chancery TeX Gyre Chorus ITC Zapf Chancery URW Palladio L Palatino Palladio URW Palatino TeX Gyre Pagella Palatino Palatino Linotype Palatino Century Schoolbook L New Century Schoolbook Century SchoolBook URW New Century Schoolbook TeX Gyre Schola New Century Schoolbook Century Schoolbook New Century Schoolbook Arimo Arial Liberation Sans Arial Liberation Sans Narrow Arial Narrow Albany Arial Albany AMT Arial Tinos Times New Roman Liberation Serif Times New Roman Thorndale Times New Roman Thorndale AMT Times New Roman Cousine Courier New Liberation Mono Courier New Cumberland Courier New Cumberland AMT Courier New Gelasio
Re: [arch-general] Booting ArchLinux with `initscripts` is now broken
Hmm... If the other message wen through, my apologies, it is completely wrong. On 19/12/14 17:13, Ciprian Dorin Craciun wrote: Hello all! I'm in a little bit of a pickle, and I would like to ask for some help with my particular setup. I haven't switched to `systemd` and I'm still booting my system with the old `initscripts` `/etc/rc.sysinit` and friends (except this all the packages are up-to-date). Before updating `systemd` from 216 to 217, it still worked. Arch switched to systemd two years ago. Using other init is not supported in core, so you are on your own. Yes, you can use any init system you wish but don't expect to get support for it except from a very small niche of stalwart users. And runit is far more exotic than SysV init. P.S.: Just to be clear, I don't want to start a systemd flame war. My reason for not using it is simple: I already use `runit` and custom scripts for all my services (except `udevd` and `agetty`), and my setup relies on somewhat modified `/etc/rc.d/functions` script for encrypted devices. You would be better off using Void Linux I think. Back up your custom setup and try with that. -- Pedro Alejandro López-Valencia http://about.me/palopezv/
Re: [arch-general] Booting ArchLinux with `initscripts` is now broken
On 19/12/14 17:13, Ciprian Dorin Craciun wrote: Hello all! I'm in a little bit of a pickle, and I would like to ask for some help with my particular setup. I haven't switched to `systemd` and I'm still booting my system with the old `initscripts` `/etc/rc.sysinit` and friends (except this all the packages are up-to-date). Before updating `systemd` from 216 to 217, it still worked. Using systemd in Arch Linux is not supported. If you want to, you are on your own. P.S.: Just to be clear, I don't want to start a systemd flame war. My reason for not using it is simple: I already use `runit` and custom scripts for all my services (except `udevd` and `agetty`), and my setup relies on somewhat modified `/etc/rc.d/functions` script for encrypted devices. Use Void Linux, you 'll get what you want. -- Pedro Alejandro López-Valencia http://about.me/palopezv/
Re: [arch-general] gnupg 2.1 not stable
On 17/12/14 16:46, Jacob Joseph wrote: On Thu, 18 Dec 2014 07:43:52 +1100 Gaetan Bisson 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 As Gaetan Bisson told you in the tracker, file the bug against emacs, where it obviously belongs. -- Pedro Alejandro López-Valencia http://about.me/palopezv/ Every nation gets the government it deserves. -- Joseph de Maistre
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
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 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 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] Missing fonts in KeePass
On 11/12/14 13:44, Sadika Sumanapala wrote: Hi, Does anyone using KeePass missing/not showing fonts? There are missing fonts in some dialog boxes (file open dialog, font dialog :) The latest gsfonts package contains fonts with different names to the ones used previously for almost 15 years. You can blame URW for the changes. But there are two little known facts: 1.) The new gsfonts are new insofar as Ghostscript.com (a.k.a. Artifex) commissioned and obtained those new and far better made fonts about four years ago but only managed to place them in a git repository sometime middle of this passing year. 2.) The old fonts used in most linux distros are a piece of c*p butchered with some incredible amateur cyrillic glyphs by using an early version of fontforge (which, at the time, was another p.o.s.). No one in his/her right mind would use those fonts (the reason why TeXLive includes its own private copy of the original unmodified URW fonts, sad it is the older versions yet). Now, to solving your problem. Fontconfig substitutes the core 35 fonts as reinterpreted by Microsoft (Times NR, Arial, Symbol MT) with the fonts in the gsfonts package and presently that is broken. You can fix it by: A.) Installing fontconfig-git from the AUR. B.) Install ttf-ms-fonts as already mentioned in this thread. C.) Do both. And while at it install ttf-carlito and ttf-caladea to replace Calibri and Cambria in all those Office 2007/2010/2013 documents out there. -- Pedro Alejandro López-Valencia http://about.me/palopezv/ Every nation gets the government it deserves. -- Joseph de Maistre
Re: [arch-general] mce after linux-3.11.5-1 on NP900X3C
On 20/11/14 20:24, Rasmus Liland wrote: [snip] I checked dmesg now after having uptime of ... [snip] ... about 26 hours. It seems after about 19 hours some (possibly) temperature related were causing mce hardware errors over a ten minute interval: [snip] As the system did not reboot, it were able to self heal. Rasmus, try using thermald (in AUR). It comes from Intel's 01.org project, so you can interpret it as a recognition of real problems with temperature regulation with Intel CPUs. -- Pedro Alejandro López-Valencia http://about.me/palopezv/ Every nation gets the government it deserves. -Joseph de Maistre
Re: [arch-general] mce after linux-3.11.5-1 on NP900X3C
On 19/11/14 16:54, Rasmus Liland wrote: This is interesting. Do you mean synchronizing via NTP protocol? My experience from this laptop is that the RTC quickly becomes desynchronized at times when I am not able to sync via OpenNTPd, i.e. when I am not connected to the internet. If so, don't use OpenNTPD but rather an ntp server that can keep track of RTC drift between reboots and also *write to the hardware clock*. chrony can do this while being lighter and simpler than ntpd.
