- Arch-general - lists.archlinux.org

[arch-general] error: GPGME error: Invalid crypto engine
by Carsten Mattner 04 Apr '14

04 Apr '14

Does someone else have problems upgrading with testing enabled since yesterday? Checked the mailing list and there's not warning that testing is broken. :: Synchronizing package databases... testing is up to date core is up to date extra is up to date community-testing is up to date community is up to date :: Starting full system upgrade... warning: bash: local (4.3.008-1) is newer than core (4.3-3) warning: readline: local (6.3.003-1) is newer than core (6.3-3) resolving dependencies... looking for inter-conflicts... Packages (1): linux-3.14-3 Total Installed Size: 69.37 MiB Net Upgrade Size: 0.00 MiB :: Proceed with installation? [Y/n] (1/1) checking keys in keyring [...] 100% error: GPGME error: Invalid crypto engine (1/1) checking package integrity [...] 100% error: GPGME error: Invalid crypto engine error: linux: missing required signature :: File /var/cache/pacman/pkg/linux-3.14-3-x86_64.pkg.tar.xz is corrupted (invalid or corrupted package (PGP signature)). Do you want to delete it? [Y/n] Same problem if I try to downgrade readline and bash :: File /var/cache/pacman/pkg/readline-6.3-3-x86_64.pkg.tar.xz is corrupted (invalid or corrupted package (PGP signature)). Do you want to delete it? [Y/n] n error: bash: missing required signature :: File /var/cache/pacman/pkg/bash-4.3-3-x86_64.pkg.tar.xz is corrupted (invalid or corrupted package (PGP signature)).

3 3

[arch-general] Trimming down our default kernel configuration
by Thomas Bächler 03 Apr '14

03 Apr '14

Hello all, it won't be too long until 3.14 is out and I want to address a topic that has been bugging me for a while. Our kernel includes everything and the kitchensink. I have no problem with delivering drivers that can be built modular, but there are other things that have an unknown impact on everyone. I want to trim our kernel down to what we actually support. 1) Once we agreed to disable one LSM, everyone else said "we can enable LSM XYZ, too". And so we did. Right now, we enable SELinux, SMACK, Tomoyo, AppArmor and Yama, although we don't support the userspace for any of those. I propose to drop all of them. 2) We patch our kernel to allow enabling CHECKPOINT_RESTORE without enabling CONFIG_EXPERT. I have no idea what the impact of this option is, other than that it was requested in order to support some tool that can freeze and save single processes resume them later. I am generally sceptical towards options that require CONFIG_EXPERT, so I propose dropping this one, too. 3) We enable tons of debug options in the "Kernel Hacking" section, many of which have a "small performance impact". I'd like to get rid of those that we don't need (I didn't go through all of them yet). What I'd like is a discussion where people suggest more things that could or should be dropped, and tell me what is absolutely needed and why. I hope that such a discussion makes it clearer to me how I should proceed. Regards Thomas

20 46

[arch-general] Apache 2.4 - Pierre was right, a post on the front page is needed
by David C. Rankin 03 Apr '14

03 Apr '14

All, The upgrade to apache 2.4 can present a real challenge for those relying on mod_php, mod_ssl and vhosts. On 2/27 on Arch-dev, Pierre suggested: "Anyway, I suggest in the end we should post an announcement on the front page." He was right. Having a few moments today to bring a production server up to date, I checked www.archlinux.org for any current warnings about breakage or that user interaction would be required for update. Finding none, I updated, and on reboot Apache 2.4 was dead in the water. WTF? Searching I find the mpm_prefork issue, since my groupware (eGroupWare) relies on mod_php. The mpm_prefork change seemed simple enough, but the server continued to fail to start. The Order deny,allow statements were rejected, numerous modules had been added/removed/renamed and httpd-ssl.conf and httpd-vhosts.conf configs failed. An hour later, after config rewrites, httpd came back to life, but will require additional study to confirm the new module mix and groupware operation. Don't get me wrong, this isn't a complaint, you guys do a fantastic job keeping arch on current release packages, but when updates to critical server applications will break existing configurations, or require user interaction, there should be a note on the front page of www.archlinux.org. This is simply to allow admins/users to adequately schedule time for an update requiring intervention when it will differ from the standard update/reboot scenario. What server packages should be considered critical? Any of the core server apps (web: apache/php, mail, auth routines, ssl/tls, etc), that will render a required part of a typical business server broken, it should be flagged. Thanks for the hard work, and so far, the sky hasn't fallen since the apache 2.4 update. Just don't get rid of mod_php, mod_fastcgi + php-fpm isn't a drop in replacement in all cases. -- David C. Rankin, J.D.,P.E.

3 2

[arch-general] pacman-key complaining, but what to do about it?
by Magnus Therning 03 Apr '14

03 Apr '14

On a newly set up system I've added the [haskell-core] repo [1], but get stuck with the following message from `pacman`: ~~~~ % sudo pacman -Syy error: haskell-testing: signature from "ArchHaskell (Magnus Therning) <magnus(a)therning.org>" is invalid :: Synchronising package databases... core 108.2 KiB 1335K/s 00:00 [##############################################] 100% haskell-testing.sig 96.0 B 0.00B/s 00:00 [##############################################] 100% error: haskell-testing: signature from "ArchHaskell (Magnus Therning) <magnus(a)therning.org>" is invalid error: failed to update haskell-testing (invalid or corrupted database (PGP signature)) extra 1565.7 KiB 1947K/s 00:01 [##############################################] 100% community 2.1 MiB 1735K/s 00:01 [##############################################] 100% multilib 115.3 KiB 1746K/s 00:00 [##############################################] 100% error: database 'haskell-testing' is not valid (invalid or corrupted database (PGP signature)) ~~~~ I've read [2] and verified (to the best of my ability) that I have correct time settings. I've also tried resetting the keys, but that doesn't improve the situation either. What else could it be? How do I find out? What can I do about it? /M [1]: https://wiki.archlinux.org/index.php/Haskell_package_guidelines [2]: https://wiki.archlinux.org/index.php/Pacman-key#Troubleshooting -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus(a)therning.org jabber: magnus(a)therning.org twitter: magthe http://therning.org/magnus

5 11

Re: [arch-general] [arch-dev-public] Linux 3.14 in [testing]
by Genes Lists 03 Apr '14

03 Apr '14

On 04/03/2014 04:10 AM, Thomas Bächler wrote: > Am 03.04.2014 05:24, schrieb Evangelos Foutras: ... >> >> Has anyone else experienced hangs in Firefox with the latest kernel? > > None that I can remember. > > I use firefox only lightly - however I too have not noticed any problems with 3.14 from rc1 through release.

1 0

[arch-general] [arch-dev-public] CAcert dropped from certificate bundle
by Neal Oakey 02 Apr '14

02 Apr '14

Hi all, because I can't send this to the arch-dev-public mailing list I will send this here: In my opinion, only because Debian drops the support for something this doesn't mean that we should do the same. And if you look at the Bugreport you will notice that the Information on which Debian is basing their argumentation is old. For more current information you can see: (sorry I know it's on German) http://www.heise.de/netze/meldung/CAcert-reagiert-auf-Zertifikatsrauswurf-2… Or http://wiki.cacert.org/Roots/EscrowAndRecovery/NRE which isn't so detailed, but should be up to date. Greetings, Neal > Hi all, > > Debian has decided to drop the root certificate of CAcert.org they used > to ship with their ca-certificates package. As our pacakge is based on > Debian's the latest ca-certficates package in [testing] also lack the > CAcert certificate. > > If we intent to keep it that way we should also remove the patch from > our nss package: > https://projects.archlinux.de/svntogit/packages.git/tree/trunk/add_spi+cace… > > The Debian bug report can be found at > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718434 > > I added the certs to our bundles in 2009. Unfortunately there is no > visible progress regarding their inclusion in browsers from Mozilla, > Google and Microsoft. > > Realistically I cannot vouch for any of the CAs we ship. That's one > reason why we push that responsibility upstream to e.g. the Debian > project or Mozilla. > > What do you think? Imho we should keep follow Debian here. Other > solutions would be to patch it back in or ship a separate optional > package; though that might be impossible for nss. > > Greetings, > > Pierre > > -- > Pierre Schmitz, https://pierre-schmitz.com <https://pierre-schmitz.com/> >

5 7

Re: [arch-general] [arch-dev-public] CAcert dropped from certificate bundle
by Neal Oakey 02 Apr '14

02 Apr '14

Hi, here you have some more detailed informations (see quote). Greetings, Neal Am 02.04.2014 23:40, schrieb Benny Baumann: > Hi, > > Am 02.04.2014 18:33, schrieb Neal Oakey: >> mit freundlichen Gruessen / best regards >> Neal Thomas Oakey >> CAcert Assurer, CAcert Event Organisation >> CAcert.org - Free Certificates >> E-Mail: neal(a)cacert.org >> >> Am 02.04.2014 17:55, schrieb Daniel Micay: >>> On 02/04/14 11:31 AM, Neal Oakey wrote: >>>> Hi, >>>> >>>> well until now all of this wasn't a problem, so why has it now become one? >>> It's becoming clearer that CAcert isn't going to be passing a third >>> party audit any time soon. Our only view into it is the open-source code > We are lacking man-power to work on solving the issues found by the > currently running audit. Details at > https://blog.cacert.org/2014/03/cacert-appoints-internal-auditor/ >>> they've made available, and messy wiki documentation. The quality of the > Anybody is free to help clean it up ... >>> code is not exactly comforting - whoever wrote most of it didn't seem to >>> be aware of prepared statements... > Which were not available when most of the code was written. And changing > the code now - which is being worked on (cf. bug #1260) will take time > and draw manpower from other places. >>>> And well if you have a look at startssl, well they may be offering free >>>> certs but only single domain and just use the plain "things". >>>> >>>> * It doesn't allow commercial usage >>>> * "only" valid for 1 year >>> A CAcert certificate isn't trusted in most major browsers or operating >>> systems, regardless of whether Arch ships it. That's a bigger > StartSSL isn't any safer just because most browsers ship them. And given > their history (3 days from founding to entering the browser stores - > you're kidding me, right)? > > And based on their crypto profile on the website (what their server > offers) you won't gain any confidence either. >>> inconvenience and makes it quite useless for commercial usage. This > Oh, funny. I know first hand that Allianz insurance and Edigas > consortium accept CAcert as advanced signatures and thus for legally > signing your business mails. Not to mention all the other businesses > using CAcert: > https://blog.cacert.org/2013/07/natural-gas-industry-accepts-cacert-gas-ind… > http://rootca.allianz.com/en/secumail_calist.htm > http://wiki.cacert.org/OrganisationAssurance/OrganisationList?highlight=%28… > > Doesn't look like it for me ... ;-) >>> isn't the only example of a free TLS certificate anyway. > Free beer vs. free speech ... >>>> * located in Israel (don't know if this should be good or bad) >>> CAcert is located in Australia. Both are US allies and cooperate with US >>> spying, if your point has something to do with the NSA. It's not like >>> Australia doesn't have an active spy agency. > Funny. Isn't like Israel is any safer from spying. Not to mention the US > where Verisign, GoDaddy, GeoTrust, ... and many other big players reside. > > Furthermore you should note that there is a motion which was passed > recently by CAcert Inc.'s board to move the incorperation to another > country. Which doesn't change the fact that even now the root keys are > neither in the US nor in Australia - both information which CAN be found > on the CAcert wiki: > http://wiki.cacert.org/Brain/CAcertInc/Committee/MeetingAgendasAndMinutes/2… > And the whereabouts of the keys can be found by looking at the > documentation of the infrastructure systems. >>>> There maybe still quite a few things that have to be worked on at CAcert >>>> but still I currently would say, >>>> that I rather trust CAcert signed certs than any other. > Which I currently do on all my systems; all other certificates are handled TOFU. > >>> You're free to add it if you trust them. Debian and Mozilla don't trust >>> them, and Pierre has made it clear that he's not in a position to vouch >>> for them either. > Debian removed them based on arguments sufficient to clear half of the > Mozilla store. Not to mention that the "there might be bugs in their > software" argument would cause the Mozilla store to be empty - some > outcome I'd really prefer to see as it'd be the ONLY honest one. >>>> I mean look at all this fuckup that these firms are doing: >>>> >>>> ... some have been removed already: >>>> >>>> * Revoking Trust in one ANSSI Certificate (*.google.com) >>>> * Revoking Trust in Two TurkTrust Certificates (*.google.com) >>>> * Revoking Trust in DigiCert Sdn. Bhd Intermediate Certificate >>>> Authority (week certs) >>>> * Fraudulent *.google.com Certificate ... => DigiNotar Removal Follow Up >>>> * Firefox Blocking Fraudulent Certificates ... => Comodo Certificate >>>> Issue -- Follow Up >>>> >>>> ... but I still see many problems: >>>> >>>> * Chromium still has (all|many) of the cert, which I listed above >>>> * still including many 1024 bit keys! (*1) >>>> * to many CAs have issued other RootCA (like for e.g.: Tekecom > DFN > >>>> every fucking university in Germany (*2)) >>>> * and how far we still can trust CAs from America, where the NSA seams >>>> to be fiddling around in the security of all important firms, I >>>> can't really say >>> The US government is far from the only country with spy agencies. The CA >>> system won't protect you from national governments, but it does a pretty >>> good job providing protection from other entities. A certificate >>> authority like CAcert without even a minimum level of security or >>> auditing in place is a liability when it comes to this. > Having a set of CAs known for having issued fake certificates aren't > much better either - even IF they happen to have found somebody signing > them credibility on some piece of paper. >>> Chromium no longer relies on the CA system for Google domains at all, it >>> simply pins the certificates instead. See > Which simply doesn't scale. >>> http://www.certificate-transparency.org/ for an example of the work >>> that's been done on to the CA system. It's a technical solution with >>> Google's political capital behind it. A CA not implementing it will have >>> EV (shiny green bar) revoked, and this happens to be a major source of >>> revenue for them. > $$$ > > And idea is, that CAcert will be implementing something like this too. > Given enough manpower things would be drastically faster though. >>>> *1: >>>>> /usr/share/ca-certificates/mozilla/Digital_Signature_Trust_Co._Global_CA_1.crt: >>>>> 1024 bit >>>>> /usr/share/ca-certificates/mozilla/Digital_Signature_Trust_Co._Global_CA_3.crt: >>>>> 1024 bit >>>>> /usr/share/ca-certificates/mozilla/Equifax_Secure_CA.crt: 1024 bit >>>>> /usr/share/ca-certificates/mozilla/Equifax_Secure_eBusiness_CA_1.crt: >>>>> 1024 bit >>>>> /usr/share/ca-certificates/mozilla/Equifax_Secure_Global_eBusiness_CA.crt: >>>>> 1024 bit >>>>> /usr/share/ca-certificates/mozilla/NetLock_Business_=Class_B=_Root.crt: 1024 >>>>> bit >>>>> /usr/share/ca-certificates/mozilla/NetLock_Express_=Class_C=_Root.crt: >>>>> 1024 bit >>>>> /usr/share/ca-certificates/mozilla/Thawte_Premium_Server_CA.crt: 1024 bit >>>>> /usr/share/ca-certificates/mozilla/Thawte_Server_CA.crt: 1024 bit >>>>> /usr/share/ca-certificates/mozilla/Verisign_Class_1_Public_Primary_Certification_Authority.crt: >>>>> 1024 bit >>>>> /usr/share/ca-certificates/mozilla/Verisign_Class_1_Public_Primary_Certification_Authority_-_G2.crt: >>>>> 1024 bit >>>>> /usr/share/ca-certificates/mozilla/Verisign_Class_2_Public_Primary_Certification_Authority_-_G2.crt: >>>>> 1024 bit >>>>> /usr/share/ca-certificates/mozilla/Verisign_Class_3_Public_Primary_Certification_Authority_2.crt: >>>>> 1024 bit >>>>> /usr/share/ca-certificates/mozilla/Verisign_Class_3_Public_Primary_Certification_Authority.crt: >>>>> 1024 bit >>>>> /usr/share/ca-certificates/mozilla/Verisign_Class_3_Public_Primary_Certification_Authority_-_G2.crt: >>>>> 1024 bit >>>> *2: >>>> if you ask me, this is just waiting for miss usage, as every university >>>> (or person which could get access to there CAs) in Germany could issue a >>>> cert for [your-bank.com] >>> Trusting CAcert in addition to these certificate authorities will not >>> improve the situation. At least these certificate authorities are >>> competent enough to pass third party audits. > Given how most IT departments in German universities are chronically > under-funded I doubt signing you some certificate would cost too much > ... And be it that on of the 64k SANs on the CSR accidentially works for > some banking website ... how unfortunate. Most IT departments lack the > practicl knowledge of how to securely operate a CA and given the high > number of apprentices I really doubt you have to search for too long to > get such a CSR signed. > > Regards, > BenBE. >

2 1

[arch-general] Using timers instead of cron jobs
by Leonid Isaev 02 Apr '14

02 Apr '14

Hi, On a current [testing] installation, there are several timer symlinks in /usr/lib/systemd/system/multi-user.target.wants (shipped with logrotate, man-db, etc.). What is the reason for choosing multi-user.target instead of timers.target? Thanks, -- Leonid Isaev GnuPG key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D

2 1

[arch-general] Linux 3.14: Kenel panic in radeon code
by Mohammad_AlSaleh 02 Apr '14

02 Apr '14

Hello. testing/linux-3.14-1 x86-64 The kernel panicked while starting X. The errors dumped pointed to the radeon module. Is anyone else seeing this regression?

1 0

Re: [arch-general] [arch-dev-public] Linux 3.14 in [testing]
by Genes Lists 02 Apr '14

02 Apr '14

On 04/01/2014 06:44 PM, Thomas Bächler wrote: > Okay, pushed everything to [testing] and [community-testing]. This may just be a mirror sync issue but I am seeing this: pacman -Syu ... looking for inter-conflicts... error: failed to prepare transaction (could not satisfy dependencies) :: bbswitch: requires linux<3.14 :: virtualbox-guest-modules: requires linux<3.14 :: virtualbox-host-modules: requires linux<3.14 gene

3 4