[gentoo-dev] Last rites: media-sound/google-musicmanager
# Andreas Sturmlechner (30 Oct 2017) # Requires dead and vulnerable qtwebkit4. # Masked for removal in 30 days. Bug #620708 media-sound/google-musicmanager
[gentoo-dev] Packages up for grabs: net-libs/http-parser
Dear all, The following packages are up for grabs: net-libs/http-parser after retirement of the proxied maintainer. https://packages.gentoo.org/packages/net-libs/http-parser The package is already in EAPI=6 and in a good state. -- Best, Jonas signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Packages up for grabs: app-misc/jail (perl)
> https://packages.gentoo.org/packages/app-misc/jail > > The proxied maintainer was also upstream. > > Jail is a Perl tool that builds a chroot and configures all the required > files, directories and libraries > https://github.com/spiculator/jail > > I do not understand why we need so many patches for the package, if > the proxied maintainer was also upstream. https://bugs.gentoo.org/514892 should explain this. > Upstream is silent since many years. I have no idea what the tool is worth. > Proxied maintainer Felix (https://bugs.gentoo.org/632752) forked the > upstram on github and can probably help us with this package. Please > contact proxy maintainer project, if you are interested. > I think, Felix plus a gentoo developer with perl experience would make a > good team. I do not really have interest in this package. The fork was just in order to be able to make a drive-by musl fix. (It was a low-hanging fruit from the list of musl build failures from blueness' tinderbox.) (Fixing https://bugs.gentoo.org/580326 would actually also fix the musl issue.) Since the upstream project has only 4 commits of which the last was in 2014, and there is no other github activity apart from my pull request, the interest in this package seems to be rather low, and I would suggest considering last-riting it. Felix
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2017-10-29 23:59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2017-10-29 23:59 UTC. Removals: app-crypt/kencfs20171028-10:03 asturm0d714555c42 dev-perl/HTML-Format20171024-06:50 kentnlc42478dd125 dev-perl/PerlIO-via-symlink 20171023-02:35 kentnl5e532d6bcc9 dev-perl/rpm-build-perl 20171023-03:25 kentnlb455abbd94d kde-misc/konstruktor20171025-17:58 asturm3791e90648a kde-misc/kookie 20171025-17:58 asturm3791e90648a media-libs/herqq20171025-17:58 asturm3791e90648a media-sound/qtmpc 20171025-17:58 asturm3791e90648a Additions: app-crypt/kencfs20171029-12:53 asturm7c5b613db15 app-text/master-pdf-editor 20171028-14:50 monsieurp 6bcb3322830 app-vim/vim-go 20171028-22:48 monsieurp 8274919bc4e dev-libs/onigmo 20171026-13:22 mrueg b7ff52308ac dev-lisp/alexandria 20171029-18:41 nimiux818a3be725c dev-perl/HTML-Formatter 20171024-06:41 kentnldbb85fc5838 dev-perl/Sys-CpuLoad20171025-18:44 kentnl334d9fe66ec dev-util/clinfo 20171025-19:01 candrews 59ab7c36ff6 sys-firmware/firmware-imx 20171026-09:40 chewi 38aa00b38a8 x11-misc/xsr20171021-08:22 monsieurp 8df6dce32e2 -- 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: app-crypt/kencfs,removed,asturm,20171028-10:03,0d714555c42 kde-misc/konstruktor,removed,asturm,20171025-17:58,3791e90648a kde-misc/kookie,removed,asturm,20171025-17:58,3791e90648a media-libs/herqq,removed,asturm,20171025-17:58,3791e90648a media-sound/qtmpc,removed,asturm,20171025-17:58,3791e90648a dev-perl/HTML-Format,removed,kentnl,20171024-06:50,c42478dd125 dev-perl/rpm-build-perl,removed,kentnl,20171023-03:25,b455abbd94d dev-perl/PerlIO-via-symlink,removed,kentnl,20171023-02:35,5e532d6bcc9 Added Packages: dev-lisp/alexandria,added,nimiux,20171029-18:41,818a3be725c app-crypt/kencfs,added,asturm,20171029-12:53,7c5b613db15 app-vim/vim-go,added,monsieurp,20171028-22:48,8274919bc4e app-text/master-pdf-editor,added,monsieurp,20171028-14:50,6bcb3322830 x11-misc/xsr,added,monsieurp,20171021-08:22,8df6dce32e2 dev-libs/onigmo,added,mrueg,20171026-13:22,b7ff52308ac sys-firmware/firmware-imx,added,chewi,20171026-09:40,38aa00b38a8 dev-util/clinfo,added,candrews,20171025-19:01,59ab7c36ff6 dev-perl/Sys-CpuLoad,added,kentnl,20171025-18:44,334d9fe66ec dev-perl/HTML-Formatter,added,kentnl,20171024-06:41,dbb85fc5838 Done.
[gentoo-dev] Last rites: net-voip/vidyodesktop
# Andreas Sturmlechner (30 Oct 2017) # Requires dead and vulnerable qtwebkit4. # Masked for removal in 30 days. Bug #620742 net-voip/vidyodesktop
[gentoo-dev] Packages up for grabs: app-misc/jail (perl)
Dear all, The following packages are up for grabs: app-misc/jail after retirement of the proxied maintainer. https://packages.gentoo.org/packages/app-misc/jail The proxied maintainer was also upstream. Jail is a Perl tool that builds a chroot and configures all the required files, directories and libraries https://github.com/spiculator/jail I do not understand why we need so many patches for the package, if the proxied maintainer was also upstream. Upstream is silent since many years. I have no idea what the tool is worth. Proxied maintainer Felix (https://bugs.gentoo.org/632752) forked the upstram on github and can probably help us with this package. Please contact proxy maintainer project, if you are interested. I think, Felix plus a gentoo developer with perl experience would make a good team. -- Best, Jonas signature.asc Description: OpenPGP digital signature
[gentoo-dev] Packages up for grabs: dev-libs/stlsoft
Dear all, The following packages are up for grabs: dev-libs/stlsoft after retirement of the proxied maintainer. https://packages.gentoo.org/packages/dev-libs/stlsoft The package was maintained by other gentoo developers since years, but needs an EAPI bump from 4 -> 6 and should use a better DESCRIPTION. Looks like an easy package to maintain. -- Best, Jonas signature.asc Description: OpenPGP digital signature
[gentoo-dev] Packages up for grabs: sys-kernel/zen-sources
Dear all, The following packages are up for grabs: sys-kernel/zen-sources after retirement of the proxied maintainer. https://packages.gentoo.org/packages/sys-kernel/zen-sources The package was maintained by other gentoo developers since years, but needs a version bump and should use a newer git eclass for all ebuilds. RepoMan scours the neighborhood... >>> Creating Manifest for /usr/local/overlays/gentoo/sys-kernel/zen-sources inherit.deprecated6 sys-kernel/zen-sources/zen-sources-3.8..ebuild: please migrate from 'git-2' to 'git-r3' on line: 17 [...] https://bugs.gentoo.org/573012 -- Best, Jonas signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] GLEP 74: Full-tree verification using Manifest files
On Sun, Oct 29, 2017 at 07:47:41PM +0100, Michał Górny wrote: ... > > If users need other values, it's a package-manager config knob. > > We don't want pre-EAPI times where things will fail out of the box > unless the user choose the one tool that got the whole list right > and/or configure it to account for default list. > > I don't mind package manager providing the ability to ignore additional > entries but the spec should work out of the box too. Ok, can we have a minor additions to the text then: - The package manager may support additional user-specified IGNORE entries, for usage where a user's processes need to inject additional files that would not be ignored by existing rules (e.g. user commits the rsync tree to CVS with -kb). Notes: - distfiles/packages/local will be in IGNORE as distributed. - package-manager might add lost+found if they have a filesystem just for the tree. > > Yes, put 'Verifying TIMESTAMP' into a new section as you added below, > > including the out-of-date part there; don't detail how to verify it in > > this section. > I will try to do this today. Looks good. > > > > > GLEP61, for the transition period, required compressed & uncompressed > > > > Manifests > > > > in the same directory to have identical content. Include mention of > > > > that here. > > > > > > Can do. But I'll do it in 'Backwards compatibility' section: > > > > - if the Manifest files inside the package directory are compressed, > > > > a uncompressed file of identical content must coexist. > > > > Saying that either can be used is a potential issue. > > > > > > Why? It also says that they must be identical, so it's of no difference > > > to the implementation which one is used. > > > > It's safe if the identical requirement is there, and potentially unsafe > > otherwise. > That's why they're both put in a *single sentence*? 'co-exist' in this context makes it the English parse weirdly to me, that's why I was worried at first. Maybe a rewrite: An uncompressed Manifest file inside a package directory MUST exist during the transition period. A compressed Manifest of identical content MAY be present. > > > But it makes no sense when top-level Manifest is signed. This points out > > > that for tools not supporting full-tree verification smaller signatures > > > need to be used (skipping the fact that Portage did not ever implement > > > it). > > The Manifests might not be signed by the same entity. > > /metadata/glsa/Manifest might be signed by the security team, > > /sec-policy/Manifest might be signed by SELinux team, > > /Manifest should STILL be signed by Infra/tree-generation-process. > I honestly doubt this will ever happen, and even if it does, it isn't > really relevant to the spec at hand. My point was: if someone signs > the whole repository, he normally will consider it pointless to sign > individual package Manifests. This explains why he might consider it. My argument is that it make sense to permit multiple levels of signature even when the top-level is signed: glsa-check could get ahead of the Portage curve by verifying /metadata/glsa/Manifest using Gemato :-). It doesn't need to verify the whole tree, just that directory. The package manager should decide about the GPG-verification of the nested Manifests however, as they convey trust from different sources. -- Robin Hugh Johnson Gentoo Linux: Dev, Infra Lead, Foundation Asst. Treasurer E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136 signature.asc Description: Digital signature
Re: [gentoo-dev] [v1.0.1] GLEP 74: Full-tree verification using Manifest files
On Sun, Oct 29, 2017 at 08:07:56PM +0100, Michał Górny wrote: > File verification model > --- > The verification model aims to provide full coverage against different > forms of attack. In particular, three different kinds of manipulation > are considered: s/three/four/ > 1. Alteration of the file content. > > 2. Removal of a file. > > 3. Addition of a new file. Add: 4. Metadata replay attacks [C08]. > In order to prevent against all three, the system requires that all > files in the repository are listed in Manifests and verified against > them. s/three/four/. > Timestamp field > --- ... > A malicious third-party may use the principles of exclusion and replay Insert [C08] after 'replay'. > Strictly speaking, this is already provided by the various > ``metadata/timestamp.*`` files provided already by Gentoo which are also > covered by the Manifest. However, including the value in the Manifest > itself has a little cost and provides the ability to perform > the verification stand-alone. Implementation Note: with TIMESTAMP, some of the old timestamp files will be obsolete; they will already need special handling in Manifest generation, because they are added VERY late in distribution. Sadly not all of them, because of legacy dependencies (they will get IGNORE entries instead, as they are populated much later than manifest generation). > References > == Additions: .. [#C08] Cappos, J et al. (2008). "Attacks on Package Managers" (https://www2.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html) -- Robin Hugh Johnson Gentoo Linux: Dev, Infra Lead, Foundation Asst. Treasurer E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136 signature.asc Description: Digital signature
[gentoo-dev] Packages up for grabs: sys-boot/os-prober
Dear all, The following packages are up for grabs: sys-boot/os-prober after retirement of the proxied maintainer. https://packages.gentoo.org/packages/sys-boot/os-prober The package was maintained by other gentoo developers since years. * sys-boot/os-prober Available versions: 1.71 ~1.74 ~1.76 Homepage:https://packages.debian.org/source/sid/os-prober Description: Utility to detect other OSs on a set of drives -- Best, Jonas signature.asc Description: OpenPGP digital signature
[gentoo-dev] [v1.0.1] GLEP 74: Full-tree verification using Manifest files
W dniu czw, 26.10.2017 o godzinie 22∶12 +0200, użytkownik Michał Górny napisał: > After a week of hard work, I'd like to request your comments > on the draft of GLEP 74. This GLEP aims to replace the old tree-signing > GLEPs 58 and 60 with a superior implementation and more complete > specification. > > The original tree-signing GLEPs were accepted a few years back but they > have never been implemented. This specification, on the other hand, > comes with a working reference implementation for the verification > algorithm. I expect to finish the update/generation part in a few days, > then work on additional optimizations (threading, incremental > verification, incremental updates). > > ReST: https://dev.gentoo.org/~mgorny/tmp/glep-0074.rst > HTML: https://dev.gentoo.org/~mgorny/tmp/glep-0074.html > impl: https://github.com/mgorny/gemato/ > > Full text following for inline comments. > Here's an updated version based on the feedback so far. Gemato is also ready for the first public testing, albeit it does not implement Gentoo- specific rules yet. --- GLEP: 74 Title: Full-tree verification using Manifest files Author: Michał Górny , Robin Hugh Johnson , Ulrich Müller Type: Standards Track Status: Draft Version: 1 Created: 2017-10-21 Last-Modified: 2017-10-29 Post-History: 2017-10-26 Content-Type: text/x-rst Requires: 59, 61 Replaces: 44, 58, 60 --- Abstract This GLEP extends the Manifest file format to cover full-tree file integrity and authenticity checks.The format aims to be future-proof, efficient and provide means of backwards compatibility. Motivation == The Manifest files as defined by GLEP 44 [#GLEP44]_ provide the current means of verifying the integrity of distfiles and package files in Gentoo. Combined with OpenPGP signatures, they provide means to ensure the authenticity of the covered files. However, as noted in GLEP 57 [#GLEP57]_ they lack the ability to provide full-tree authenticity verification as they do not cover any files outside the package directory. In particular, they provide multiple ways for a third party to inject malicious code into the ebuild environment. Historically, the topic of providing authenticity coverage for the whole repository has been mentioned multiple times. The most noteworthy effort are GLEPs 58 [#GLEP58]_ and 60 [#GLEP60]_ by Robin H. Johnson from 2008. They were accepted by the Council in 2010 but have never been implemented. When potential implementation work started in 2017, a new discussion about the specification arose. It prompted the creation of a competing GLEP that would provide a redesigned alternative to the old GLEPs. This specification is designed with the following goals in mind: 1. It should provide means to ensure the authenticity of the complete repository, including preventing the injection of additional files. 2. Like the original Manifest2, the files should be split into two groups — files whose authenticity is critical, and those whose mismatch may be accepted in non-strict mode. The same classification should apply both to files listed in Manifests, and to stray files present only in the repository. 3. The format should be universal enough to work both for the Gentoo repository and third-party repositories of different characteristics. 4. The Manifest files should be verifiable stand-alone, that is without knowing any details about the underlying repository format. Specification = Manifest file format This specification reuses and extends the Manifest file format defined in GLEP 44 [#GLEP44]_. For the purpose of it, the *file type* field is repurposed as a generic *tag* that could also indicate additional (non-checksum) metadata. Appropriately, those tags can be followed by other space-separated values. Unless specified otherwise, the paths used in the Manifest files are relative to the directory containing the Manifest file. The paths must not reference the parent directory (``..``). Manifest file locations and nesting --- The ``Manifest`` file located in the root directory of the repository is called top-level Manifest, and it is used to perform the full-tree verification. In order to verify the authenticity, it must be signed using OpenPGP, using the armored cleartext format. The top-level Manifest may reference sub-Manifests contained in subdirectories of the repository. The sub-Manifests are traditionally named ``Manifest``; however, the implementation must support arbitrary names, including the possibility of multiple (split) Manifests for a single directory. The sub-Manifest can only cover the files inside the directory tree where it resides. The sub-Manifest can also be signed using OpenPGP armored cleartext format. However, the signature verification can be omitted if it is covered by a signed top-level Manifest. The Manifest files can also specify ``IGNORE`` entries to skip Manifest ver
[gentoo-dev] Packages up for grabs: net-misc/pavuk
Dear all, The following packages are up for grabs: net-misc/pavuk after retirement of the proxied maintainer. https://packages.gentoo.org/packages/net-misc/pavuk The package is in a bad state and has open bugs: https://bugs.gentoo.org/buglist.cgi?quicksearch=net-misc%2Fpavuk We should last rite it, if no one wants to fix it. -- Best, Jonas signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] GLEP 74: Full-tree verification using Manifest files
W dniu sob, 28.10.2017 o godzinie 18∶44 +, użytkownik Robin H. Johnson napisał: > On Sat, Oct 28, 2017 at 01:50:46PM +0200, Michał Górny wrote: > > > A SVN or Git repo might also have dot-named directories. > > > > I like the implicit idea better as it is more consistent with normal > > tool behavior, like 'ls' not listing the files. Dotfiles can be created > > by many random tools or even the filesystem (especially in some cases > > of overlay filesystems). > > > > That said, the case of 'lost+found' just occurred to me. I suppose this > > one we will want to always IGNORE. > > Thought: make the package manager responsible for their own ignore list > in addition to the IGNORE values; and by default it can contain a > partial overlap with the IGNORE manifest entries. > **/.git > /lost+found # ignore at the top-level only > /distfiles # ignore at the top-level only > /packages # ignore at the top-level only > /local # ignore at the top-level only > > If users need other values, it's a package-manager config knob. We don't want pre-EAPI times where things will fail out of the box unless the user choose the one tool that got the whole list right and/or configure it to account for default list. I don't mind package manager providing the ability to ignore additional entries but the spec should work out of the box too. > > > Let's try: > > > > > 2. Start at the top-level Manifest file. Verify its OpenPGP signature. > > >Optionally verify the ``TIMESTAMP`` entry if present. > > >If the timestamp is significantly out of date compared to the local > > >clock or a trusted source, halt or require manual intervention > > >from the user. Remove the top-level Manifest from the *present* set. > > > > Maybe it would look better if I split it into sub-points. > > Yes, put 'Verifying TIMESTAMP' into a new section as you added below, > including the out-of-date part there; don't detail how to verify it in > this section. I will try to do this today. > > > GLEP61, for the transition period, required compressed & uncompressed > > > Manifests > > > in the same directory to have identical content. Include mention of that > > > here. > > > > Can do. But I'll do it in 'Backwards compatibility' section: > > > - if the Manifest files inside the package directory are compressed, > > > a uncompressed file of identical content must coexist. > > > Saying that either can be used is a potential issue. > > > > Why? It also says that they must be identical, so it's of no difference > > to the implementation which one is used. > > It's safe if the identical requirement is there, and potentially unsafe > otherwise. That's why they're both put in a *single sentence*? > > > > Timestamp field > > > > > > A malicious third-party may use the principles of exclusion and replay > > > to deny an update to clients, while at the same time recording > > > the identity of clients to attack. The timestamp field can be used > > > to detect that. > > > > > > In order to provide a more complete protection, the Gentoo > > > Infrastructure should provide an ability to obtain the timestamps > > > of all Manifests from a recent timeframe over a secure channel > > > for comparison. > > > > > > Strictly speaking, this is already provided by the various > > > ``metadata/timestamp.*`` files provided already by Gentoo which are also > > > covered by the Manifest. However, including the value in the Manifest > > > itself has a little cost and provides the ability to perform > > > the verification stand-alone. > > Just add in the sentence re trusted source from before, otherwise good. > The rest of this thread devolved into specifics about implementing the > validation; which aren't relevant to this GLEP (yes, telling the package > manager that it's a known old tree, ignore the age only, is a valid use > case). Ok. > > > Could we please note here, for the transitional period, that the > > > file equivalence rule is applicable? > > > During the transitional, the package Manifests may contain two entries > > > for a > > > given file: (DATA, EBUILD) or (DATA, AUX). The MISC type remains the > > > same. > > > > Equivalence rule is applicable always. However, there's no point > > in duplicating the entry for the same file as that's only going > > to increase space use. > > This means that new verification tools (beyond Gemato) need to handle > the legacy types for the moment, and can't just skip them (eg if both > entries existed). Which is the easier way forward. Otherwise, we end up having a lot of duplication during the transition period (which would amount to 2 years at the very least, and probably a lot more). > > > > > - the Manifest files inside the package directory can be signed > > > > to provide authenticity verification. > > > > > > Why do we need to specify this in backwards compat, it's still permitted > > > above. > > > > But it makes no sense when top-level Manifest is signed. This points out > > t
[gentoo-dev] Packages up for grabs: x11-misc/sunflower
Dear all, The following packages are up for grabs: x11-misc/sunflower after retirement of the proxied maintainer. https://packages.gentoo.org/packages/x11-misc/sunflower Description: Small and highly customizable twin-panel file manager with plugin-support I think cleaning the ebuild and a version bump would be a good next step for this package RepoMan scours the neighborhood... >>> Creating Manifest for /usr/local/overlays/gentoo/x11-misc/sunflower inherit.deprecated1 x11-misc/sunflower/sunflower-0.2_alpha59.ebuild: please migrate from 'fdo-mime' to 'xdg-utils' on line: 7 Changelog is here: https://github.com/MeanEYE/Sunflower/blob/develop/CHANGES It is available on other distributions already https://repology.org/metapackage/sunflower/versions -- Best, Jonas signature.asc Description: OpenPGP digital signature
[gentoo-dev] Packages up for grabs: dev-embedded/avra
Dear all, The following packages are up for grabs: dev-embedded/avra after retirement of the proxied maintainer. (https://bugs.gentoo.org/633094) https://packages.gentoo.org/packages/dev-embedded/avra A bump to EAPI=6 would be a good new start for this package. Upstream made the last release in 2010 http://avra.sourceforge.net/ -- Best, Jonas signature.asc Description: OpenPGP digital signature
[gentoo-dev] Packages up for grabs: media-video/rovclock
Dear all, The following packages are up for grabs: media-video/rovclock after retirement of the proxied maintainer. (https://bugs.gentoo.org/632896 was also upstream) https://packages.gentoo.org/packages/media-video/rovclock The primary question is, if it is worth to keep it in the tree: The ebuild provides "Overclocking utility for ATI Radeon cards" which were produced till ~2005, Cards reported to work: Radeon 7500 Radeon 8500 Radeon 9000 Radeon 9100 Radeon 9500 (Pro) Radeon 9550 Radeon 9600 Mobility FireGL T2 Mobility Radeon 9600 M10 Radeon 9700 (Pro) Radeon X800XL the upstream project is dead since January 2006. http://www.hasw.net/linux/index.html If we want to keep this in the tree, it would be great, if a new maintainer would simply stabilize rovclock-0.6e-r1.ebuild which is already EAPI=6 and delete the obsolete rovclock-0.6e.ebuild -- Best, Jonas signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: app-crypt/kencfs
# Andreas Sturmlechner (29 Oct 2017) # Dead upstream, depends on dead kdelibs4/Qt4. # Use kde-plasma/plasma-vault or app-crypt/kencfs-plasma instead. # Masked for removal in 30 days. app-crypt/kencfs
Re: [gentoo-dev] Packages up for grabs: sys-process/parallel
> Possibly worth CC'ing to the proxy-maint ML too? No, I do not think so. Cross postings must be avoided where possible. -- Best, Jonas signature.asc Description: OpenPGP digital signature
