[arch-dev-public] Edit /etc/php/php.ini config file in chroot
Hi, I am using devtools to create a package with php scripts. It uses composer to build the package. I get the error: The requested PHP extension ext-iconv * is missing from your system. Install or enable PHP's iconv extension. This can be solved by editing the config file and add: extension=iconv The config file is only accessible by root. How do I edit this config file within the PKGBUILD if its build by devtools? Any idea? ~Nico signature.asc Description: OpenPGP digital signature
[arch-dev-public] .gnuog owned by root when using devtools in first place
I ran extra-x86_64-build on a new system with an uninitialized gnupg keyring. I think it was responsible for creating a .~/gnupg directory, but with root privilegs. I chowned it to my user, it is all good now. Maybe the script could be improved to check if the gnupg keyring was initialzed or not, to prevent such issues. I was confused in the first place. ~Nico signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] switching to systemd-stable
On 07/06/2017 09:44 AM, NicoHood wrote: > And yes, I am doing stuff in the background. I wrote a guide and a tool > that simplifies source code signing[1] and I am doing a detailed > security analysis on all ArchLinux packages. And once it is ready I will > request gpg signatures from every upstream source, especially packages > from [core]. > Forgot the reference: [1] https://github.com/NicoHood/gpgit signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] switching to systemd-stable
On 07/06/2017 09:12 AM, Bartłomiej Piotrowski wrote: > On 2017-07-06 02:11, NicoHood wrote: >> On 07/05/2017 12:10 AM, Christian Hesse wrote: >>> Dave Reisner on Sat, 2017/07/01 13:22: >>>> Hey all, >>>> >>>> This should be pretty much a no-brainer, but wanted to be sure I wasn't >>>> missing anything. Systemd upstream publishes a "systemd-stable" repo [1] >>>> which branches at each tag and cherry-picks backports. I'd like to >>>> switch our systemd package to this repo to avoid some of the duplication >>>> of work that Jan, Christian and myself have done in the past. The repo >>>> sees a bunch more activity than what our own backporting strategy has >>>> been, and I see that as a positive. >>> >>> Just a little heads-up... systemd 233.75-1 landed in [testing]. So give it a >>> try! ;) >>> >>> BTW, we had just one backported commit to be removed, so 74 new commits >>> landed in this package compared to 233-7. Let's hope this gives some >>> benefit. >>> >> >> Systemd still does not use https sources. Regarding the recent >> discussion about tricking git about wrong tags and other evil stuff it >> is highly recommended to switch to https. Please do it in favor for all >> ArchLinux users security. >> >> Once more the reference: >> https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/torres-arias >> > > Regarding the recent discussion: > > https://lists.archlinux.org/pipermail/arch-dev-public/2017-July/028919.html > > I really hoped I don't have to put "NicoHood" on top to make you realize > it's addressed to you. Please do it in favor for all Arch Linux packagers. > What are you blaming me for now? This is a package everyone must install and you are telling me we have other serious problems? Sure we have, but compared to the time it takes to add an "s" to "http" this is a simple excuse. And this is not about checksums man, this is about https where even gpg signatures by git can be tricked. And yes, I am doing stuff in the background. I wrote a guide and a tool that simplifies source code signing[1] and I am doing a detailed security analysis on all ArchLinux packages. And once it is ready I will request gpg signatures from every upstream source, especially packages from [core]. So you can tell me discussing about this is bullshit, right. But just not reacting to obvious security problems that can be solved within seconds is just not a single time better. Please do it in favor for all Arch Linux User's Security. signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] switching to systemd-stable
On 07/05/2017 12:10 AM, Christian Hesse wrote: > Dave Reisner on Sat, 2017/07/01 13:22: >> Hey all, >> >> This should be pretty much a no-brainer, but wanted to be sure I wasn't >> missing anything. Systemd upstream publishes a "systemd-stable" repo [1] >> which branches at each tag and cherry-picks backports. I'd like to >> switch our systemd package to this repo to avoid some of the duplication >> of work that Jan, Christian and myself have done in the past. The repo >> sees a bunch more activity than what our own backporting strategy has >> been, and I see that as a positive. > > Just a little heads-up... systemd 233.75-1 landed in [testing]. So give it a > try! ;) > > BTW, we had just one backported commit to be removed, so 74 new commits > landed in this package compared to 233-7. Let's hope this gives some benefit. > Systemd still does not use https sources. Regarding the recent discussion about tricking git about wrong tags and other evil stuff it is highly recommended to switch to https. Please do it in favor for all ArchLinux users security. Once more the reference: https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/torres-arias signature.asc Description: OpenPGP digital signature
[arch-dev-public] ArchLinux on Github
Hi, we have an organization on Github: https://github.com/archlinux Would it be possible to add my account (NicoHood) also to this organization? This would help other users to identify that i am also an ArchLinux TU Member. Cheers, Nico signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Shadowing i686, round 1
On 12/13/2016 08:04 PM, Balló György via arch-dev-public wrote: > 2016. 12. 13, kedd keltezéssel 12.29-kor Doug Newgard ezt írta: >> On Tue, 13 Dec 2016 19:16:53 +0100 >> Balló György via arch-dev-public >> wrote: >> >>> -1 for dropping i686 completely. >>> >>> +1 for introducing automated builds, even if it's less secure. >>> >>> I would like to keep i686 supported, and willing to do anything >>> that is >>> needed to setup and maintain an official automated build server for >>> i686 packages (and possibly for other architectures). >> >> I've got to ask, why do you feel so strongly about it? It's been >> pointed out >> that i686 really doesn't fit in with the original goals of Arch >> anymore, is less >> and less supported upstream, and essentially untested. What is the >> compelling >> reason for keeping it around? > > Because I still use an i686-only system occasionally, and I prefer to > keep old hardware working with my favourite distribution. I agree that > building packages manually for a small percentage of users is > pointless. But most of the packages can be built for i686 without any > modifications. We just need an automated build server, which takes the > job. > > -- > György Balló > Trusted User > If we have reproduceable builds we could also use this buildserver to build the x64 packages. I know that this is a huge task, but then we could automate the package building better in a centralized place. And instead of dropping i686 we could integrate arm as well. Those will not be officially supported, but we could give people access to fix those arch specific problems. Normal maintainers can focus on x64 development while some others have a place to distribute and maintain other architectures of their favorite os. signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Shadowing i686, round 1
On 12/12/2016 10:02 PM, Jelle van der Waa wrote: > On 12/12/16 at 09:51pm, Bartłomiej Piotrowski wrote: >> against that architecture. No, I don't do even smoke tests – I assume >> that i686 works if x86_64 does. (Don't beat me up too hard for that.) > > I know for sure that you are not the only one :) > >> I'd like to set a certain date of dropping i686 completely. During that >> time, community and/or interested packagers could come up with either >> automated build solution, making it "tier 2" architecture. Otherwise it >> would just die of natural cause. > > I'm in favor of an auto build solution, since this has multiple > bonusses. We could extend the auto build solution for reproducible > builds (yay!). Auto rebuilds and maybe later when vendors get their act > togehter (aarch64 *cough*). > I agree to get rid of i686. However I want to refer to the discussion about stronger hashes in PKGBUILDs. If we use an automatic build solution that builds the packages for 32bit, we need to make sure that we have gpg signed sources or strong hashes. GPG signatures would be best, but if they are not available we must rely on the hash. To ensure that the build server downloads the exact same source as the maintainer (who checked and tested the source) we must use strong hashes. (This already applies for the ALARM project). Now that some packages still need some arch dependent modification I would still add those, if possible. It would mean our PKGBUILD is compatible with 32bit, but does not guarantee it. I personally would also love to do this for ARM, as it is just a really small change sometimes to add support for a specific arch. This way the build server maintainers do not need to patch every PKGBUILD (considering trivial changes). I can see it as volunteer addition of the maintainer in this case. ~Nico signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Moving arduino into [community] important notes
On 12/02/2016 08:32 PM, Bartłomiej Piotrowski wrote: >> On 11/28/2016 08:26 AM, Antonio Rojas wrote: >>> El Mon, 28 Nov 2016 01:34:38 +0100, Bartłomiej Piotrowski escribió: >>> There is no way to remove epoch, ever. I know it looks ugly for some packagers, but there is nothing to be ashamed for. We have it for a reason, and if it's been added, it stays. >>> >>> I thought AUR packages were unsupported. Sure, it is nice to give them a >>> higher version number when they are moved to the official repos to allow >>> for a smooth upgrade, but that shouldn't be an enforced rule IMO. And >>> removing epoch is a reasonable enough reason not to do it. >>> >> >> I agree with that too. And with the other arguments above this can be >> justified if you ask me. If we do it this way it would be easier for >> others to notice the change and fix their installation. Without a news >> people will start contacting me or on IRC how the hell they can fix >> arduino (as AUR will the not exist anymore). > > So on one hand you say that it deserves a news post and on the other you > agree that AUR should be considered unsupported. Seems contradictory? > > Anyway, it looks like it could be handled with post_upgrade function. > The problematic directory can be simply removed, you can also print > message saying about deleting ~/.arduino15 (but guard it with vercmp > please). > > Bartłomiej > Alright. I will just add a note in the upgrade install file, but no hardcoded remove command which might break other packages. Can you give me an example of the vercmp? I guess I only need to print this note for pre 1.6.12 upgrades then. Thats also a good suggestion. signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Moving arduino into [community] important notes
On 11/28/2016 01:34 AM, Bartłomiej Piotrowski wrote: > On 2016-11-26 18:01, NicoHood wrote: >> Hey guys, >> I've got a few concerns when moving arduino into community. Lately we >> could solve most bugs, but those require some manual installation steps >> that I want to explain here, and those possibly need additional >> information on the front page: >> >> Some (very old) arduino installations (somehow) left over the empty path >> /usr/share/arduino/hardware/avr which will cause a crash with the new >> arduino installation: >> java.io.FileNotFoundException: >> /usr/share/arduino/hardware/arduino/avr/platform.txt (No such file or >> directory) > > How did it get created in the first place? > It must be a leftover from some old AUR packages. I myself cannot reproduce this bug, I only got this reported from a few other users who've been using arduino longer than I maintained it. I dont want to call it a pacman bug (possibly not anymore), otherwise its possibly black magic. However this happened to quite some people. >> The 2nd issue is when people try to upgrade from an older version of >> arduino that provided arduino-builder. It will fail to install as the >> new version says "oh, arduino-builder is already installed". It then >> tries to remove arduino and the arduino-builder dependency is not >> satisfied anymore. This only affects a small number of versions, but >> still raise up on AUR. I am not sure if this got fixed in pacman by now. > > I don't understand this point. What fails to install new version? What > pacman bug you are talking about? As far as I remember this got fixed. I also tried to reproduce this and it seems it got fixed. > >> Since such many upgrade problems raised up, I think it is highly >> recommended to sum those up in a short news at archlinux.org and then >> push arduino to community. > > Because of your vague description, it's hard to say if that's true. > Especially because so many problems occurred it would make sense to let people know to uninstall and the reinstall arduino. >> While people will likely have to remove their >> existing installation, I think it would also make sense to get rid of >> the current epoche value at the same time when it moves to community. As >> an alternative we could also rename arduino to arduino-ide and add a >> replace into the PKGBUILD. > > There is no way to remove epoch, ever. I know it looks ugly for some > packagers, but there is nothing to be ashamed for. We have it for a > reason, and if it's been added, it stays. > > Bartłomiej > > On 11/28/2016 08:26 AM, Antonio Rojas wrote: > El Mon, 28 Nov 2016 01:34:38 +0100, Bartłomiej Piotrowski escribió: > >> There is no way to remove epoch, ever. I know it looks ugly for some >> packagers, but there is nothing to be ashamed for. We have it for a >> reason, and if it's been added, it stays. > > I thought AUR packages were unsupported. Sure, it is nice to give them a > higher version number when they are moved to the official repos to allow > for a smooth upgrade, but that shouldn't be an enforced rule IMO. And > removing epoch is a reasonable enough reason not to do it. > I agree with that too. And with the other arguments above this can be justified if you ask me. If we do it this way it would be easier for others to notice the change and fix their installation. Without a news people will start contacting me or on IRC how the hell they can fix arduino (as AUR will the not exist anymore). It would just make sense to do the suggested steps. If you dont want, I dont need to. My installation works, other peoples possibly dont. Cheers Nico signature.asc Description: OpenPGP digital signature
[arch-dev-public] Stronger Hashes for PKGBUILDs
It has been discussed and suggested from a lot of different people[1] that we should use stronger hashes inside our PKGBUILDs. Since we now must check for and use https and GPG when that is possible[2], we should also consider making the switch to stronger hashes. Server cracks and MitM attacks could lead to the fetching of tampered source files that are used for package building. This can be dangerous when older packages must be rebuilt automatically or are modified. Using a weak hash function's message digests for verification could lead to the use of tampered source files without us noticing that. Especially when https and GPG cannot be used, it is a must to use strong hashes for verifying the integrity of the sources. **The usage of weak hash function algorithms (md5 and sha1) must be avoided.** sha512 must become the default. If upstream uses message digests of weak hash function algorithms, the message digests of those can also be included in the PKGBUILD files, and those message digests should be seen as an additional check. Stronger hashes have **no disadvantages, they can only improve security**. We should also change the default value of INTEGRITY_CHECK in /etc/makepkg.conf to use sha512 by default, as suggested multiple times on the bugtracker[1]. The wiki[3] needs to be changed accordingly to our new GPG, https and hash guidelines. We as ArchLinux Distribution should try to provide our Users the best security of our packages as well as the PKGBUILDs. Thanks for all your support! [1] Depreciate md5 and sha1 https://lists.archlinux.org/pipermail/arch-general/2009-January/003215.html https://bugs.archlinux.org/task/51236 https://bugs.archlinux.org/task/39210 https://bugs.archlinux.org/task/38543 https://bugs.archlinux.org/task/12772 [2] https and GPG https://lists.archlinux.org/pipermail/arch-dev-public/2016-October/028416.html https://www.archlinux.org/todo/use-gpg-signatures-and-https-sources/ [3] https://wiki.archlinux.org/index.php/PKGBUILD#Integrity signature.asc Description: OpenPGP digital signature
[arch-dev-public] Moving arduino into [community] important notes
Hey guys, I've got a few concerns when moving arduino into community. Lately we could solve most bugs, but those require some manual installation steps that I want to explain here, and those possibly need additional information on the front page: Some (very old) arduino installations (somehow) left over the empty path /usr/share/arduino/hardware/avr which will cause a crash with the new arduino installation: java.io.FileNotFoundException: /usr/share/arduino/hardware/arduino/avr/platform.txt (No such file or directory) -> To resolve this issue you need to remove arduino and manually delete the folder. You might also want to check if there are any other folder zombies inside the arduino path. If this still does not help it might also be an idea to delete (backup before) ~/.arduino15 The 2nd issue is when people try to upgrade from an older version of arduino that provided arduino-builder. It will fail to install as the new version says "oh, arduino-builder is already installed". It then tries to remove arduino and the arduino-builder dependency is not satisfied anymore. This only affects a small number of versions, but still raise up on AUR. I am not sure if this got fixed in pacman by now. -> To resolve this issue you need to remove arduino first and then reinstall it. The version issue that some of you got seems to be only the case when you use a 3rd party tool like arturo. It got fixed now. Arduino now uses the upstream avr-gcc within the optional package arduino-avr-core which should be installed if you want to use avr boards. You can still use their older avr-gcc 4.9, see the wiki for more details. Since such many upgrade problems raised up, I think it is highly recommended to sum those up in a short news at archlinux.org and then push arduino to community. While people will likely have to remove their existing installation, I think it would also make sense to get rid of the current epoche value at the same time when it moves to community. As an alternative we could also rename arduino to arduino-ide and add a replace into the PKGBUILD. I am also working on getting the build system fix into upstream and also to sign their upstream sources. Thanks a lot for all the feedback so far from AUR and IRC! To sum up, the news should contain: * Remove arduino manually first * Delete /usr/share/arduino/hardware/avr if it still exists * check for other folder zombies in /usr/share/arduino * Install arduino * Consider to install the new optional deps arduino-avr-core and arduino-docs * Consider to also to start with a clean ~/.arduino15 folder if any other problem occurs * Read the wiki about further details or contact me personally Any comments on that? Cheers, Nico 0xC1AE9161.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] todo list for moving http -> https sources
I'd also vote for https. It does not hurt to use a secure channel to download the sources from. It would be great if we as ArchLinux team could make the first step into that direction. However if you write such a script, it should also check if an https download is available, as not all websites provide https downloads yet (sadly). Using PGP signatures is another discussion, also the hash algorithm. I think we should discuss that in another post, appart from https. From my point of view its highly important to use a strong hash function as its highly important for the source integrity and not only meant as checksum for corruption detection. And as always: more secure does not hurt nowadays Cheers, Nico signature.asc Description: OpenPGP digital signature
