[gentoo-dev] RFC: introduce RUST_TARGETS use-expand (take2)
Hi, sending again, accidentally sent from personal email first time and it's stuck somewhere. I would like to introduce new USE_EXPAND in profiles for rusts 3 consumers in the tree: dev-lang/rust dev-lang/rust-bin sys-devel/rust-std and maybe virtual, but not sure yet, may be required for firefox. The idea: Rust supports building as many targets as one wants, as long as C toolchan can do it and matching llvm target is enabled on rust or llvm. There are some special rust targets that require same host toolchain but are treated like separate targets in rust. For example x86_64-unknown-linux-gnu target is primary on amd64, but on multilib profiles we can easily enable i686-unknown-linux-gnu target and it will just work (that's how multilib in rust works now) Another example is arm: armv7-unknown-linux-gnueabihf is primary toolchain. but rust supports additional target thumbv7neon-unknown-linux-gnueabihf, which requires exactly same host toolchain, but is capable of emitting thumb-neon binaries. This is required by firefox if --enable-neon is passed in firefox build. Another example: ppc64 We can easily build both ppc64 and ppc64le targets in a single bootstrap with host toolchain, and rust will support emitting code for both endians. Another example: musl On musl we need 1 extra target with gentoo vendor field. So installing both x86_64-unknown-linux-musl x86_64-gentoo-linux-musl will be very easy, as both targets use same C toolchain, but slightly different settings. And last, but not the least, it allows cross support if matching toolchain is installed (tested with crossdev) A user can unmask the following targets on amd64 rust_targets_thumbv7neon-unknown-linux-gnueabihf rust_targets_armv7-unknown-linux-gnueabihf And as long as they have /usr/armv7a-unknown-linux-gnueabihf toolchain available at build time, and llvm_targets_ARM enabled, rust will bootstrap itself in a way that it will be able to emit code for any of 3 targets enable. This is optional opt-in functionality. And just to clarify, native host toolchain is not going to be a use-expand, at least that's how I imagine it now. Native target matching CHOST is always build without any flags, and is the default target for rust. But I may re-evaluate it and introduce requirements like abi_x86_64?? ( rust_targets_x86_64-unknown-linux-gnu ) abi_x86_32? ( rust_targets_i686-unknown-linux-gnu ) for multilib profiles. and something like this for non-multilib arches. ppc64? ( || rust_targets_powerpc64le-unknown-linux-gnu rust_targets_powerpc64-unknown-linux-gnu ) for example, similar to as llvm does with LLVM_TARGETS. Of course default targets will be use-forced via profiles. But if possible I'd avoid it. Proof of concept exists (without using expand flags for now) in both rust and rust-bin ebuilds. Multilib is implemented that way and has been working great for more than a year, also experimental cross support in rust implemented that way, and users are already able to define as many targets as they want, but it feels hacky and I would like to move forward to targets approach and make it trackable via flags, and not magic variables nobody knows about. Initial rollout will require a bit of arch profile masking (like llvm does it) and maybe new eclass to reduce boilerplate code in ebuilds, but nothing to complex. WDYT? tracking bug https://bugs.gentoo.org/747760 cross bugs: https://bugs.gentoo.org/679878 https://bugs.gentoo.org/680652 https://bugs.gentoo.org/689336 Regards, Georgy.
[gentoo-dev] Re: RFC: introduce RUST_TARGETS use-expand
On 10/10/20 7:17 PM, Georgy Yakovlev wrote: Hi, Sorry, thunderbird used personal mailfrom for some reason. Probably an issue after update. OpenPGP_0xA5EDB076475B46A6.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Refactor display manager openrc init scripts to independent package
On 10/10/20 2:18 PM, Ulrich Mueller wrote: >> On Sat, 10 Oct 2020, Aisha Tammy wrote: > >> On 10/10/20 8:00 AM, Joonas Niilola wrote: - xdm init.d is replaced by display-manager init.d script >>> >>> Why this rename? I can't find a reason for that. >>> >> The name change was to make it clear that its separate from xorg-server >> as it no longer has any ties to xdm. >> display-manager can be run without having xdm on your system. > > Still sounds like a rename for the sake of renaming. /etc/init.d/xdm > is already now a generic init script and not tied to any specific > display manager. > > Since this will affect users' systems (and maybe require manual > intervention), I think you'll need a better reason for renaming. > Manual intervention is going to be needed in any case. The display manager inits are independent scripts and need to be installed manually as none of the display managers have a dependency on it. In which case it makes sense to also make it clear what these scripts are for and to not overload the xdm term for both the actual dm and also the init script. > Ulrich > signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] tagging deprecated eclasses internally
On 2020-09-26 Sat 05:23, Ulrich Mueller wrote: > IIUC the authoritative document for eclass documentation is the > description of the format in the eclass-to-manpage.awk script, so this > would be a good start to add support for a new tag. Initial awk implementation available at [1], but currently only supports showing eclass deprecation replacement/message even though all tag groups are supported. I'm open to ideas for how variable/function deprecation tag info should be formatted for manpages. The tag syntax is currently the following: # @DEPRECATED: # This could be simplified to a single line if we want to force the usage of @DESCRIPTION for additional deprecation info, but I think splitting long deprecation info out is helpful. [1]: https://github.com/mgorny/eclass-to-manpage/pull/4
Re: [gentoo-dev] [PATCH 1/5] verify-sig.eclass: New eclass to verify OpenPGP sigs
On Sat, 2020-10-10 at 22:10 +0200, Thomas Deutschmann wrote: > Another example for something that was not thought to the end and which > was rushed and pushed to our users. You start this mail with an insult to me. Why do you keep doing this? Do you feel that there is some special need for you to try to diminish me in order to reach your goal? > Sorry for being late to this but any > addition should really add a benefit. What is the benefit verify-sig is > adding? > > When mgorny started to propose this in #-qa, he used the argument to > improve security of Gentoo because we cannot know if every Gentoo > developer is really verifying distfiles or just copying ebuild to new > version and let `repoman commit` fetch the distfile and be done with the > bump. While I agree with the idea in general, i.e. when you would be > able to provide an automatism for that, that would be a great addition. > > But there is a problem. > > You cannot automate trust. > > And anyone who is trying to do that shows that he/she does not > understand how signing works and because of the fact he/she will claim > security was improved, security was actually lowered due to that. It would be nice if you could lead your argument in another way than 'see, public, he must be wrong, he does not understand what he is doing!' > How is that? > > Because the statement you can get from a signature depends on the trust > in the used key. I.e. you assume that the key used to create that > signature is only accessible by the designated owner and that nobody > else have access to it. In the moment you learn that somebody else > gained access to that key, i.e. can create signatures using the same > key, you can no longer trust that key. More important, you should start > questioning previously seen signatures (if you take it serious you will > distrust any files signed by that key and demand on a new signature with > a new key where you managed to establish a new trust). > > Short excerpt: > Code signing is nothing new. It is an important layer in Microsoft’s > security defense. Even Apple is relying on signatures for their sandbox > they introduced some years ago. But does a signature prevent anything? > Of course not. StuxNet was signed with a valid signature from Realtek > Semiconductor Corp. and switched later to a signature which belongs to > JMicron Technology Corp when Realtek’s signature got revoked. A > post-mortem analysis suggested that cybercriminals compromised both > organizations and have stolen their development certificates, including > the private keys used to sign the executables. In 2014, when Sony > Pictures got hacked, attackers had signed the malware with valid > certificates from *Sony*. But that is only the tip of the iceberg, see > https://attack.mitre.org/techniques/T1553/002/ for more examples. My > point here is, and I believe we all agree on this, that signatures alone > are meaningless. > > To add a meaning to signatures you must trust the signer that he/she > will immediately revoke the certificate once he/she gets aware that an > unauthorized third party gained access to the certificate. If we, for an > unknown reason, assume that this will happen, we will face another > problem: We must receive this information. If we do not know that > something has happened to the key, we will not take any actions. > I guess you all still remember how you created your GPG key for Gentoo, > don’t you? Do you still have access to the revocation certificate you > created during that process? I am sure you do. But do you know how this > process works? Right, you need to upload that certificate to a key > server. But then 2019 happened. Key servers are dead now. You can no > longer rely on key servers, especially not that once you have uploaded > your revocation certificate that it will spread and reach users. Just do > an easy exercise: Check who committed to Gentoo repository in past 6 > months. Now try to fetch the GPG key of all committers without using > *.gentoo.org. Good luck! And no, WKD cannot help you with that (revocation). > > Coming back to my initial statement that it is all about automatization. Thank you for coming back to the point. I understand that an important point in every argument is to include a lot of text but our (readers!) time is limited. > > The whole idea started with assumption that not every developer will > verify the distfile (an assumption I share). But why should we trust > these developers that they will keep an eye on upstream’s used > certificate instead? That does not make any sense for me. This sounds like 'perfect is the enemy of good'. If we can't get this done perfectly good, we should just lie down and do not put any effort into making things better. > Another point I just want to mention was patch 5 of 6 for > net-libs/miniupnpc. Did you notice that the ebuild will fetch public key > via HTTP instead of HTTPS? Is this
Re: [gentoo-dev] [PATCH 1/5] verify-sig.eclass: New eclass to verify OpenPGP sigs
Hi, I am really unhappy with this addition. Another example for something that was not thought to the end and which was rushed and pushed to our users. Sorry for being late to this but any addition should really add a benefit. What is the benefit verify-sig is adding? When mgorny started to propose this in #-qa, he used the argument to improve security of Gentoo because we cannot know if every Gentoo developer is really verifying distfiles or just copying ebuild to new version and let `repoman commit` fetch the distfile and be done with the bump. While I agree with the idea in general, i.e. when you would be able to provide an automatism for that, that would be a great addition. But there is a problem. You cannot automate trust. And anyone who is trying to do that shows that he/she does not understand how signing works and because of the fact he/she will claim security was improved, security was actually lowered due to that. How is that? Because the statement you can get from a signature depends on the trust in the used key. I.e. you assume that the key used to create that signature is only accessible by the designated owner and that nobody else have access to it. In the moment you learn that somebody else gained access to that key, i.e. can create signatures using the same key, you can no longer trust that key. More important, you should start questioning previously seen signatures (if you take it serious you will distrust any files signed by that key and demand on a new signature with a new key where you managed to establish a new trust). Short excerpt: Code signing is nothing new. It is an important layer in Microsoft’s security defense. Even Apple is relying on signatures for their sandbox they introduced some years ago. But does a signature prevent anything? Of course not. StuxNet was signed with a valid signature from Realtek Semiconductor Corp. and switched later to a signature which belongs to JMicron Technology Corp when Realtek’s signature got revoked. A post-mortem analysis suggested that cybercriminals compromised both organizations and have stolen their development certificates, including the private keys used to sign the executables. In 2014, when Sony Pictures got hacked, attackers had signed the malware with valid certificates from *Sony*. But that is only the tip of the iceberg, see https://attack.mitre.org/techniques/T1553/002/ for more examples. My point here is, and I believe we all agree on this, that signatures alone are meaningless. To add a meaning to signatures you must trust the signer that he/she will immediately revoke the certificate once he/she gets aware that an unauthorized third party gained access to the certificate. If we, for an unknown reason, assume that this will happen, we will face another problem: We must receive this information. If we do not know that something has happened to the key, we will not take any actions. I guess you all still remember how you created your GPG key for Gentoo, don’t you? Do you still have access to the revocation certificate you created during that process? I am sure you do. But do you know how this process works? Right, you need to upload that certificate to a key server. But then 2019 happened. Key servers are dead now. You can no longer rely on key servers, especially not that once you have uploaded your revocation certificate that it will spread and reach users. Just do an easy exercise: Check who committed to Gentoo repository in past 6 months. Now try to fetch the GPG key of all committers without using *.gentoo.org. Good luck! And no, WKD cannot help you with that (revocation). Coming back to my initial statement that it is all about automatization. The whole idea started with assumption that not every developer will verify the distfile (an assumption I share). But why should we trust these developers that they will keep an eye on upstream’s used certificate instead? That does not make any sense for me. Another point I just want to mention was patch 5 of 6 for net-libs/miniupnpc. Did you notice that the ebuild will fetch public key via HTTP instead of HTTPS? This will create a chicken-egg problem here: We will record key information metadata the same way we store information about distfiles which is temper proofed. But because this is happening in an automatic way there is not just a theoretical chance that we will store an attacker’s key in our metadata because who is going to verify they key? The same developer we distrust (or where we just want to avoid to trust) that he/she verified the distfile? Do you see the contradiction? Please do not get me wrong. I like the idea. But I also understand that you cannot implement it in a secure and really working way -- you will always require a human paying attention. But now that we pretend, we managed to implement that and even show a fancy green message that we verified (any) signature, we actually lowe
Re: [gentoo-dev] [RFC] Refactor display manager openrc init scripts to independent package
> On Sat, 10 Oct 2020, Aisha Tammy wrote: > On 10/10/20 8:00 AM, Joonas Niilola wrote: >>> - xdm init.d is replaced by display-manager init.d script >> >> Why this rename? I can't find a reason for that. >> > The name change was to make it clear that its separate from xorg-server > as it no longer has any ties to xdm. > display-manager can be run without having xdm on your system. Still sounds like a rename for the sake of renaming. /etc/init.d/xdm is already now a generic init script and not tied to any specific display manager. Since this will affect users' systems (and maybe require manual intervention), I think you'll need a better reason for renaming. Ulrich signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Refactor display manager openrc init scripts to independent package
On 10/10/20 8:00 AM, Joonas Niilola wrote: > > On 10/10/20 1:57 PM, Aisha Tammy wrote: >> Hi all, >> This change is for OpenRC init scripts only. >> Currently the way our display managers are started, is by using the >> xdm init script present in the xorg-base/xorg-server package, with its >> script >> dependencies spread across four other packages, without any logical >> separation. >> This makes it so that every display manager needs the whole xorg-server >> package even if just for the init scripts. >> There are bugs open about this for a while to refactor the scripts out >> from >> xorg-server and into their own independent package, to make them easier >> to manage and modify >> - https://bugs.gentoo.org/730644 >> - https://bugs.gentoo.org/356915 >> The change is not just for the sake of closing bugs either. >> Given the recent number of huge additions in wayland, it is now possible >> to have a Xorg-free setup starting from the display manager. >> There are wayland-only display-managers available in gentoo >> - gui-apps/gtkgreet >> - gui-apps/tuigreet >> >> It should now be possible to start these display managers using openrc >> without pulling in Xorg. >> >> The changes are currently being worked on in the PR at >> https://github.com/gentoo/gentoo/pull/16554 > > +1 to separating xdm from xorg-server. > > >> >> Changes >> - xdm init.d is replaced by display-manager init.d script > > Why this rename? I can't find a reason for that. > The name change was to make it clear that its separate from xorg-server as it no longer has any ties to xdm. display-manager can be run without having xdm on your system. > >> - Configuration of display-manager is done similar to xdm by modifying >> /etc/conf.d/display-manager >> - Add display-manager to default runlevel and it should start working > > My counter-proposal at this point would be to handle DMs similarily to > how it's done with systemd. In other words, every DM would provide their > own init and conf files (or, "service" files) and they'd be controlled This is quite hard as openrc manages tty handling differently than systemd. Currently display-managers work by adding an extra run level in openrc (see https://github.com/gentoo/gentoo/pull/16554/files#diff-6d89a718d595e0c0516c6d6b96bd4cd5R21) It is not possible to do this independently for each of lightdm/gdm/sddm separately, there would be too much redundant copying of code. > like that. I really see no point in renaming xdm to display-manager. xdm > to gdm, xdm to lightdm etc causes at least the same amount of confusion > and hassle, but would at least match the other init system. Then > swapping between openrc and systemd would be one step less difficult. > > I have both openrc and systemd systems installed, and find the systemd > way a lot cleaner in this regard. What would other people think? > > -- juippis > > >> >> Other changes, less relevant to everyday users >> - boot parameter nox has been replaced by nogui >> - usage of /etc/.nox has been removed in favor of /run/.nogui as the >> boot >> parameter is a better controller >> >> Cheers, >> Aisha >> > signature.asc Description: OpenPGP digital signature
[gentoo-dev] [RFC] Refactor display manager openrc init scripts to independent package
Hi all, This change is for OpenRC init scripts only. Currently the way our display managers are started, is by using the xdm init script present in the xorg-base/xorg-server package, with its script dependencies spread across four other packages, without any logical separation. This makes it so that every display manager needs the whole xorg-server package even if just for the init scripts. There are bugs open about this for a while to refactor the scripts out from xorg-server and into their own independent package, to make them easier to manage and modify - https://bugs.gentoo.org/730644 - https://bugs.gentoo.org/356915 The change is not just for the sake of closing bugs either. Given the recent number of huge additions in wayland, it is now possible to have a Xorg-free setup starting from the display manager. There are wayland-only display-managers available in gentoo - gui-apps/gtkgreet - gui-apps/tuigreet It should now be possible to start these display managers using openrc without pulling in Xorg. The changes are currently being worked on in the PR at https://github.com/gentoo/gentoo/pull/16554 Changes - xdm init.d is replaced by display-manager init.d script - Configuration of display-manager is done similar to xdm by modifying /etc/conf.d/display-manager - Add display-manager to default runlevel and it should start working Other changes, less relevant to everyday users - boot parameter nox has been replaced by nogui - usage of /etc/.nox has been removed in favor of /run/.nogui as the boot parameter is a better controller Cheers, Aisha
Re: [gentoo-dev] [RFC] Refactor display manager openrc init scripts to independent package
On 10/10/20 1:57 PM, Aisha Tammy wrote: > Hi all, > This change is for OpenRC init scripts only. > Currently the way our display managers are started, is by using the > xdm init script present in the xorg-base/xorg-server package, with its > script > dependencies spread across four other packages, without any logical > separation. > This makes it so that every display manager needs the whole xorg-server > package even if just for the init scripts. > There are bugs open about this for a while to refactor the scripts out > from > xorg-server and into their own independent package, to make them easier > to manage and modify > - https://bugs.gentoo.org/730644 > - https://bugs.gentoo.org/356915 > The change is not just for the sake of closing bugs either. > Given the recent number of huge additions in wayland, it is now possible > to have a Xorg-free setup starting from the display manager. > There are wayland-only display-managers available in gentoo > - gui-apps/gtkgreet > - gui-apps/tuigreet > > It should now be possible to start these display managers using openrc > without pulling in Xorg. > > The changes are currently being worked on in the PR at > https://github.com/gentoo/gentoo/pull/16554 +1 to separating xdm from xorg-server. > > Changes > - xdm init.d is replaced by display-manager init.d script Why this rename? I can't find a reason for that. > - Configuration of display-manager is done similar to xdm by modifying > /etc/conf.d/display-manager > - Add display-manager to default runlevel and it should start working My counter-proposal at this point would be to handle DMs similarily to how it's done with systemd. In other words, every DM would provide their own init and conf files (or, "service" files) and they'd be controlled like that. I really see no point in renaming xdm to display-manager. xdm to gdm, xdm to lightdm etc causes at least the same amount of confusion and hassle, but would at least match the other init system. Then swapping between openrc and systemd would be one step less difficult. I have both openrc and systemd systems installed, and find the systemd way a lot cleaner in this regard. What would other people think? -- juippis > > Other changes, less relevant to everyday users > - boot parameter nox has been replaced by nogui > - usage of /etc/.nox has been removed in favor of /run/.nogui as the > boot > parameter is a better controller > > Cheers, > Aisha > OpenPGP_signature Description: OpenPGP digital signature
