Re: [gentoo-dev] Policy-level discussion for minimum versions on dependencies
On 11/09/2013 06:02 PM, Matt Turner wrote: On Sat, Nov 9, 2013 at 4:28 AM, Andreas K. Huettel dilfri...@gentoo.org wrote: Am Samstag, 9. November 2013, 02:19:32 schrieb Ben de Groot: On 8 November 2013 08:55, Rémi Cardona r...@gentoo.org wrote: Le jeudi 07 novembre 2013 à 10:44 +0100, Alexis Ballier a écrit : in short: if a package requires version X then the ebuild should require version X; it can be forgotten but it's a bug. That _is_ our policy. Since this thread was deemed necessary, apparently it's not. Or at least not clearly stated. It was not clear, and we should officially clarify it somewhere in the documentation. (I also learnt as a recruit that versionless dependency is fine if all versions in the portage tree fulfill it. As a consequence I have been regularly dropping version dependencies from ebuilds for simplification if the excluded versions were long gone from the tree.) For what gain? It seems to only allow breakage when updating old systems I've also dropped minimum version requirements in the past. I wonder if there a performance hit? If every package in the tree specified min versions of all its dependencies, would resolution of emerge -avuDN world take longer? (It does take a couple of minutes already on my aging laptop...) Cheers, Thomas -- Thomas Kahle signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Suggestion: support the Dev team with system resources
08.11.2013 09:04, Johann Schmitz пишет: On 07.11.2013 21:18, Rich Freeman wrote: Seriously, though, I'd love to see these needs better supported. I think we need to start by defining what the needs actually are (less redundancy, more consistency, etc). Then we figure out how to best address them. It could be individuals donating VMs, or it might be Gentoo buying resources from any number of vendors, or it could be Gentoo going out and looking for donors. I agree with that. It's easier to decide what to do if we know what we need. A solution built by the infra team would be the best solution for the same reasons why it's better to put stuff on the devspace instead of private servers (availabilty; who can fix stuff, logins, etc). But if someone need resources and a box to play with I would happily provide an Xen instance. Just wondering: How is the AT for $minorarch done? Is it possible to run, say, mips on xen/whatever through some emulation layer or is real hardware a requirement for this archs? For the security concerns: I think these boxes should be used for testing only and not for development - every commit must be done from a box fully under the dev's control. Usually it is done via qemu, but as was said - it is damn slow. I use qemu for emulating ARM device for compilation, cause it's faster than compile on device(Raspberry Pi) itself mostly because of I/O. -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop-effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Drop net-analyzer/nagios-* to maintainer-needed
On 11/09/2013 09:20 AM, Diego Elio Pettenò wrote: Seems like I forgot to select reply all earlier. I'm going to look into that next week. I failed to resetup my monitoring after I left my previous customer and I've reinstalled icinga just this week. I don't understand people's insistence with a single product herd given we don't have enough manpower yet and I don't want to have an explosion of aliases I need to subscribe to, the spam is enough as it is. If you are interested in co-maintaining with me I'd be interested in helping with the plugins (nrpe/nsca agent/plugins and pnp4nagios). I already do the icinga packages but I feel like I am starting to spread myself thing with openstack and everything :( -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
[gentoo-dev] GLEP proposal: Gentoo GPG key policies
Foreword: This a wrap up of my previous email RFC: Gentoo GPG key policies, from 2013/02/18, incorporating all of the changes from the thread at the time. http://thread.gmane.org/gmane.linux.gentoo.devel/83996 This thread does contain other implementation suggestions for Repoman, but I think that is outside the scope of this GLEP. Apologies if my GLEP formatting is a bit rusty, it's been a while since I wrote one, and I wasn't sure how to combine many of the pieces of information here. Suggestions on breaking down the information differently welcomed. This should hopefully be a sufficient final proposal for the council to take as strongly guidelines and/or a GLEP. This was originally intended to be part of the tree-signing GLEP series, but was in one of the unpublished ones (GLEPxx+3 in the references). GLEP: xx Title: Gentoo GPG key policies Version: x Last-Modified: x Author: Robin H. Johnson robb...@gentoo.org Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 2013/02/18 Post-History: 2013/11/10 Credits: Many developers and external sources helped in this GLEP. Abstract: = This GLEP provides a both a minimum requirement and a recommended set of GPG key management policies for the Gentoo Linux distribution. Motivation: === ... Specification: == Bare minimum requirements: -- 1. SHA2-series output digest (SHA1 digests internally permitted). personal-digest-preferences SHA256 2. root key signing subkey of EITHER: 2.1. DSA, 2048-bit 2.1.1. Exception: if your hardware token only supports 1024-bit, you may use it 2.2. RSA, =2048 bits, 2.2.1. RSAv4 or later only: v3 and older are FORBIDDEN. 3. Key expiry: 5 years max. Recommendations: 0. Copy /usr/share/gnupg/gpg-conf.skel to ~/.gnupg/gpg.conf, append the block given in step 5 of the FAQ. TODO: The upstream skeleton config file has improved over the years, it would be useful for all users to get updates to it, but etc-update only works for /etc, since this is deployed per-user. Suggestions welcome on getting users to do this. 1. SHA2-series digest on output certifications: personal-digest-preferences SHA256 cert-digest-algo SHA256 2. Root key type of RSAv4, 4096 bits 2.1. This may require creating an entirely new key. 3. Dedicated signing subkey of EITHER: 3.1. DSA 2048 bits exactly. 3.2. RSA 4096 bits exactly. 4. Key expiry: 4.1. Root key: 3 year max, expiry renewed annually. 4.2. Gentoo subkey: 1 year max, expiry renewed every 6 months. 5. Create a revocation certificate store it hardcopy offsite securely (it's about ~300 bytes). 6. Encrypted backup of your secret keys. 7. In your gpg.conf: :: # include an unambiguous indicator of which key made a signature: # (and http://www.ietf.org/mail-archive/web/openpgp/current/msg00405.html) # (see http://thread.gmane.org/gmane.mail.notmuch.general/3721/focus=7234) sig-notation issuer-...@notations.openpgp.fifthhorseman.net=%g Notes/FAQ: -- 1. Ok, so how do I follow this? [#DEBIANGPG]_ [#EKAIA]_ 2. How can I be really sure/paranoid enough? [#RISEUP]_. 3. Every 3-6 months, and/or before key expiry and major keysigning events, you should update your key expiry date with the 'expire' command (remember to do all subkeys). Put it on your calendar! 4. If you intend to sign on a very slow alternative-arch, you may find adding a DSA1024 subkey significantly speeds up the signing. TODO: should we codify this exception? 5. Can you give me a full ~/.gnupg/gpg.conf file? :: keyserver pool.sks-keyservers.net emit-version default-recipient-self # -- All of the below portion from the RiseUp.net OpenPGP best practices, and # -- many of them are also in the Debian GPG documentation. # when outputting certificates, view user IDs distinctly from keys: fixed-list-mode # long keyids are more collision-resistant than short keyids (it's trivial to make a key with any desired short keyid) keyid-format 0xlong # when multiple digests are supported by all recipients, choose the strongest one: personal-digest-preferences SHA512 SHA384 SHA256 SHA224 # preferences chosen for new keys should prioritize stronger algorithms: default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 BZIP2 ZLIB ZIP Uncompressed # If you use a graphical environment (and even if you don't) you should be using an agent: # (similar arguments as https://www.debian-administration.org/users/dkg/weblog/64) use-agent # You should always know at a glance which User IDs gpg thinks are legitimately bound to the keys in your keyring: verify-options show-uid-validity list-options show-uid-validity # include an unambiguous
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2013-11-10 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2013-11-10 23h59 UTC. Removals: x11-themes/qtcurve-qt4 2013-11-04 04:54:16 yngwin net-im/python-otr 2013-11-09 18:10:16 hanno dev-games/gigi 2013-11-10 14:14:48 tomka games-strategy/seven-kingdoms-data 2013-11-10 15:38:27 pinkbyte Additions: dev-ruby/debugger-linecache 2013-11-05 03:19:43 mrueg dev-ruby/lumberjack 2013-11-05 03:37:11 mrueg dev-perl/autovivification 2013-11-05 03:58:00 mrueg net-analyzer/gr-fosphor 2013-11-05 16:22:01 chithanh games-misc/doge 2013-11-05 18:14:44 vikraman sys-devel/byfl 2013-11-05 20:38:23 ottxor dev-vcs/bfg 2013-11-06 04:25:48 radhermit dev-perl/Term-ReadLine-TTYtter 2013-11-06 17:42:47 hwoarang app-misc/elasticsearch 2013-11-07 09:19:22 chainsaw media-gfx/aaphoto 2013-11-07 10:45:11 pinkbyte games-action/armagetronad 2013-11-07 18:48:05 hasufell dev-python/turbolift2013-11-08 00:43:58 prometheanfire dev-ruby/tdiff 2013-11-09 10:23:31 graaff dev-ruby/nokogiri-diff 2013-11-09 15:51:26 graaff net-misc/bgpq3 2013-11-10 15:33:19 pinkbyte -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: x11-themes/qtcurve-qt4,removed,yngwin,2013-11-04 04:54:16 net-im/python-otr,removed,hanno,2013-11-09 18:10:16 dev-games/gigi,removed,tomka,2013-11-10 14:14:48 games-strategy/seven-kingdoms-data,removed,pinkbyte,2013-11-10 15:38:27 Added Packages: dev-ruby/debugger-linecache,added,mrueg,2013-11-05 03:19:43 dev-ruby/lumberjack,added,mrueg,2013-11-05 03:37:11 dev-perl/autovivification,added,mrueg,2013-11-05 03:58:00 net-analyzer/gr-fosphor,added,chithanh,2013-11-05 16:22:01 games-misc/doge,added,vikraman,2013-11-05 18:14:44 sys-devel/byfl,added,ottxor,2013-11-05 20:38:23 dev-vcs/bfg,added,radhermit,2013-11-06 04:25:48 dev-perl/Term-ReadLine-TTYtter,added,hwoarang,2013-11-06 17:42:47 app-misc/elasticsearch,added,chainsaw,2013-11-07 09:19:22 media-gfx/aaphoto,added,pinkbyte,2013-11-07 10:45:11 games-action/armagetronad,added,hasufell,2013-11-07 18:48:05 dev-python/turbolift,added,prometheanfire,2013-11-08 00:43:58 dev-ruby/tdiff,added,graaff,2013-11-09 10:23:31 dev-ruby/nokogiri-diff,added,graaff,2013-11-09 15:51:26 net-misc/bgpq3,added,pinkbyte,2013-11-10 15:33:19 Done.
Re: [gentoo-dev] GLEP proposal: Gentoo GPG key policies
On Mon, 2013-11-11 at 00:01 +, Robin H. Johnson wrote:
Gentoo LDAP:
All developers must list the complete GPG fingerprint for their root
keys in the gpgfingerprint LDAP field.
It should be exactly 40 hex digits, uppercase, with optional spaces
every 8 hex digits. Regular expression for validation: ^[[:xdigit]]{8}(
?[[:xdigit]]{8}){4}$
The problem I can see happening allowing the optional spaces is that
currently the fingerpint field is a space separated list of
fingerprints. In the ldap-seeds code used to generate the
developer.seeds file. I am splitting that field data on the spaces to
get a python list of individual fingerprints. There are developers that
have 2 fingerprints listed. If spaces are to be allowed in the
fingerprint then we will need to use and enforce a different separator
to divide the fingerprints. Currently in gentoo-keys I use the : as a
separator in the gpgkey and fingerprint fields of the seed file. A |
is used to separate the fields of the seed info.
The prior gpgkey field will be removed, as it is a subset of the
fingerprint field. In any place that presently displays the gpgkey
field, the last 16 hex digits of the fingerprint should be displayed
instead.
++
Currently running some checks on the gpgkey and fingerprint fields,
there are many developers with errors. Some have 2 gpgkeys listed, but
only 1 fingerprint, some the gpgkey does not match the fingerprint. One
dev's fingerprint is only 39 chars in length. Please check if yours has
errors and correct them please. See below for the links.
By eliminating the gpgkey field in ldap it will reduce the chance for
errors and is redundant data anyway. I will later establish a policy
code to test the developer.seeds file to look for errors in installing
the keys before it is pushed to the server for public download. I
already have code to install the complete set of developer seeds, but
need to add/tweak the code to log the errors correctly.
For the current file of the valid developer seeds:
http://dev.gentoo.org/~dolsen/developer.seeds
record entries are 1 dev per line.
fields are ['nick', 'name', 'keyid', 'longkeyid','keydir', 'fingerprint']
For the latest log of the seed file generation run which lists the
errors found:
http://dev.gentoo.org/~dolsen/gkeyldap-latest.log
P.S. If any python coders are interested in helping, please contact
me :)
Tools:
==
We have most of the key-tracking in progress in the gentoo-keys project
[#GENTOOKEYS]_.
This toolset should also include easy-to-use tools for developers to generate
new keys [#TOOLSET]_ (using the recommendations) and update expiry dates.
This tool should generate a final user-formatted keyring, to be hosted on the
Gentoo API site.
Backwards Compatibility:
There is no consistent standard for GPG usage in Gentoo to date.
There is conflicting information in the Devmanual [#DEVMANUAL-MANIFEST]_
and the GnuPG Gentoo user guide [#GNUPG-USER]_. As there is little
enforcement of Manifest signing and very little commit signing to date,
there are no backwards compatibility concerns.
External documentation:
===
Much of the above was driven by the following:
- NIST SP 800-57 recommendations [#NIST-SP800-57-1]_,
[##NIST-SP800-57-2]_
- Debian GPG documentation [#DEBIANGPG]_
- RiseUp.net OpenPGP best practices [#RISEUP]_
References:
===
.. [#GENTOOKEYS] Gentoo Keys project
(http://git.overlays.gentoo.org/gitweb/?p=proj/gentoo-keys.git)
.. [#TOOLSET]
http://thread.gmane.org/gmane.linux.gentoo.devel/83996/focus=84220
.. [#NIST-SP800-57-1] NIST SP 800-57: Recommendation for Key Management: Part
1: General (Revision 3)
(http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf)
.. [#NIST-SP800-57-2] NIST SP 800-57: Recommendation for Key Management: Part
2: Best Practices for Key Management Organization
(http://csrc.nist.gov/publications/nistpubs/800-57/SP800-57-Part2.pdf)
.. [#EKAIA] Ana's blog: Creating a new GPG key
(http://ekaia.org/blog/2009/05/10/creating-new-gpgkey/)
.. [#DEBIANGPG] Debian GPG documentation
(https://wiki.debian.org/Keysigning)
.. [#RISEUP] RiseUp.net OpenPGP best practices
(https://we.riseup.net/riseuplabs+paow/openpgp-best-practices)
.. [#DEVMANUAL-MANIFEST] Gentoo Development Guide: Manifest
(http://devmanual.gentoo.org/general-concepts/manifest/index.html)
.. [#GNUPG-USER] GnuPG Gentoo User Guide
(http://www.gentoo.org/doc/en/gnupg-user.xml)
--
Brian Dolbec dol...@gentoo.org
signature.asc
Description: This is a digitally signed message part
