Re: How to deal with "assets" packages shadowing real upstream
Quoting Paul Wise (2016-02-29 04:30:02) > On Mon, Feb 29, 2016 at 5:05 AM, Antonio Terceiro wrote: > >> IMO both in this specific case, and in the general case, the correct >> technical decision is to track the actual upstream as a proper >> Javascript package (supporting both browser usage and NodeJS, if it >> makes sense), and make the convenience packages for other languages >> use and depend on the proper Javascript one. Do I read you correctly that in your opinion it _is_ a severe bug to not follow the actual upstream when available. I would agree with that. So what next? Do I simply try assume it is a severe bug even if not written into Policy yet, and see if others agree with that - enough that eventually we can conclude that yes this should probably be written into Policy? >> I think this situation is exactly the same as convenience copies of C >> libraries: we always want to have a single copy of each library in >> the archive, first because of security updates, but also to keep some >> level of sanity. In most cases we will be able to do that, and in a >> few cases we will have to make -- temporary, one hopes -- exceptions. > > Agreed. In the case of exceptions, please tell the security team about > them: > > https://wiki.debian.org/EmbeddedCodeCopies I believe you mean exceptions of having only one copy of some code in Debian. What I talk about is exceptions to code being tracked from its real source, which I believe is not tracked anywhere, nor treated as a security matter in general - I believe it is not currently recognized as a matter of concern at all, generally in Debian. That is why I ask how to improve on that (assuming others agree it is something we want to improve on). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#816247: general: hardening distro is an afterthought
Richard Jasmin, on Sun 28 Feb 2016 22:42:00 -0600, wrote: >(With hardened by default config for source builds) Hardening does break some packages, you can't just go away with forcing it. Samuel
Bug#816247: marked as done (general: hardening distro is an afterthought)
Your message dated Mon, 29 Feb 2016 09:51:54 + with message-id <1456739514.3098.91.ca...@decadent.org.uk> and subject line Re: Bug#816247: general: hardening distro is an afterthought has caused the Debian Bug report #816247, regarding general: hardening distro is an afterthought to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 816247: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=816247 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: general Severity: normal Tags: newcomer upstream patch Dear Maintainer, In RE of my overview of debian security(and the forced do-it-yourself mentality) I am providing a general coverage of hardening policy with Debian STABLE. There is much to learn from other distros here, namely the INDUSTRY LEADER, RED HAT. Of note is the change in Fedora 23 to the distro base. Two major changes are noted: Mono to v4 Better hardened system packages in the repos (With hardened by default config for source builds) And a CLEAR snapshot of running processes hilights the problem. Debian IS NOT THERE YET. I know SOME processes may be nearly impossible to harden, but the WHOLE system? [wide view] Look at all that NO PIE and Partial RELRO Hackers have stated that NX is a moot point. It can be bypassed. Stack canaries as well, but they do slow them down. --- systemd 1351 Full RELROCanary found NX enabledPIE enabled lxsession 1367 Partial RELRO Canary found NX enabled No PIE dbus-launch 1391 Partial RELRO Canary found NX enabled No PIE dbus-daemon 1392 Partial RELRO Canary found NX enabled No PIE gvfsd 1403 Partial RELRO Canary found NX enabled No PIE gvfsd-fuse 1407 Partial RELRO Canary found NX enabled No PIE openbox 1491 Full RELROCanary found NX enabled PIE enabled lxpolkit 1494 Partial RELRO Canary found NX enabled No PIE lxpanel 1497 Full RELROCanary found NX enabled PIE enabled pcmanfm 1499 Full RELROCanary found NX enabled PIE enabled xscreensaver 1500 Partial RELRO Canary found NX enabled No PIE gvfs-udisks2-vo 1508 Partial RELRO Canary found NX enabled No PIE wicd-client 1510 Partial RELRO Canary found NX enabled No PIE mate-volume-con 1520 Partial RELRO Canary found NX enabled No PIE nm-applet 1532 Partial RELRO Canary found NX enabled No PIE gvfs-afc-volume 1544 Partial RELRO Canary found NX enabled No PIE at-spi-bus-laun 1547 Full RELROCanary found NX enabled PIE enabled dbus-daemon 1551 Partial RELRO Canary found NX enabled No PIE at-spi2-registr 1554 Full RELROCanary found NX enabled PIE enabled notification-da 1557 Partial RELRO Canary found NX enabled No PIE mate-screensave 1562 Partial RELRO Canary found NX enabled No PIE gvfs-mtp-volume 1565 Partial RELRO Canary found NX enabled No PIE gvfs-goa-volume 1579 Partial RELRO Canary found NX enabled No PIE gconfd-2 1585 Partial RELRO Canary found NX enabled No PIE clipit 1589 Full RELROCanary found NX enabled PIE enabled pulseaudio 1592 Full RELROCanary found NX enabled No PIE gvfs-gphoto2-vo 1603 Partial RELRO Canary found NX enabled No PIE menu-cached 1616 Partial RELRO Canary found NX enabled No PIE gvfsd-trash 1624 Partial RELRO Canary found NX enabled No PIE start-pulseaudi 1643 Full RELROCanary found NX enabled PIE enabled xprop 1644 Partial RELRO Canary found NX enabled No PIE lxterminal 16673 Partial RELRO Canary found NX enabled No PIE bash 16675 Partial RELRO Canary found NX enabled No PIE bash 16677 Partial RELRO Canary found NX enabled No PIE dconf-service 17709 Partial RELRO Canary found NX enabled No PIE ssh 18617 Full RELROCanary found NX enabled PIE enabled sshfs 18621 Full RELROCanary found NX enabled PIE enabled kdeinit4 20831 Partial RELRO Canary found NX enabled No PIE klauncher 20834 Partial RELRO Canary fo
dh_gencontrol debug symbol wrapper: no debian/-dbgsym, skipping package
Hi everyone, I'd like to play around with the (new) auto dbgsym packages, and for starters build Mixxx [1] on launchpad's Xenial environment (featuring debhelper 9.20160115ubuntu2). Instead of an auto dbg package, however, I'm getting ``` dh_gencontrol debug symbol wrapper: no debian/mixxx-dbgsym, skipping package mixxx ``` Is this a server misconfig, or am I actually missing something from the package? Cheers, Nico [1] alioth:/git/pkg-multimedia/mixxx.git
Bug#816273: ITP: python-jellyfish -- Python library for doing approximate and phonetic matching of strings
Package: wnpp Severity: wishlist Owner: "Víctor Cuadrado Juan" * Package name: python-jellyfish Version : 0.5.2 Upstream Author : James Turk * URL : https://github.com/jamesturk/jellyfish * License : BSD-2-clause Programming Lang: C, Python Description : Python library for doing approximate and phonetic matching of strings It uses the following string comparison Algorithms (it provides C and Python implementation): * Levenshtein Distance * Damerau-Levenshtein Distance * Jaro Distance * Jaro-Winkler Distance * Match Rating Approach Comparison * Hamming Distance . Supports the following phonetic encoding: * American Soundex * Metaphone * NYSIIS (New York State Identification and Intelligence System) * Match Rating Codex It is a little library, but does its job. I intend to maintain this package under the DPMT (which I am part of). This package is a dependency for beets, #775719, which is lagging some versions [1]. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775719 -- Víctor Cuadrado juan E-Mail: , OpenPGP-Key-ID: 0xA2591E231E251F36 Key fingerprint: E3C5 114C 0C5B 4C49 BA03 0991 A259 1E23 1E25 1F36 My signed E-Mails are trustworthy. signature.asc Description: PGP signature
Re: dh_gencontrol debug symbol wrapper: no debian/-dbgsym, skipping package
Hi, Nico Schlömer writes: > I'd like to play around with the (new) auto dbgsym packages, and for > starters build Mixxx [1] on launchpad's Xenial environment (featuring > debhelper 9.20160115ubuntu2). Instead of an auto dbg package, however, I'm > getting > ``` > dh_gencontrol debug symbol wrapper: no debian/mixxx-dbgsym, skipping > package mixxx > ``` > Is this a server misconfig, or am I actually missing something from the > package? As far as I know Ubuntu implements automatic debug symbols in a different way and only for the main archive. I don't think you will get any automatic debug symbols for local builds or PPA uploads. An Ubuntu development list probably is a better place to ask how automatic debug symbols work there. Ansgar
RFP: elusive-icons -- the iconic font and CSS framework
Package: wnpp Severity: wishlist * Package name: elusive-icons Version : 2.0.0 Upstream Author : The Redux Team * URL : http://elusiveicons.com/ * License : SIL OFL 1.1, Expat Programming Lang: Text + CSS Description : the iconic font and CSS framework Long-Description: Elusive Icons is a full suite of 304 pictographic icons for easy scalable vector graphics on websites, created and maintained by Team Redux. Rationales: The fonts provided by this source package are required for the python-qtawesome source package, which currently uses an embedded copy.
Re: [Pkg-php-pecl] Bug#816265: Bug#816265: Bug#816265: Bug#816265: php-geoip: FTBFS: libtool: No such file or directory
Sergey, please, I already have explained to you, that the bug has been fixed in php7.0-dev version 7.0.3-4 and higher, and there's nothing that can be done before the kfreebsd-* builds are not stuck at the perl and snmp transitions there are blocking php7.0 builds. As you clearly don't belive me, I am Ccing this email to debian-devel, so somebody else you might believe will confirm the severities in non-release archs and status of kfreebsd-* I simply cannot fix an architecture that is lagging behind in the builds of packages that has already fixed the underlying problem. I simply lack the magic powers to modify binary packages by my pure will, so we'll have to wait for new builds. Yes, it would be better if libtool would add "Breaks: php7.0-dev (<< 7.0.3-4), but the milk has been already spilled, and unless src:php7.0 >= 7.0.3-4 will be built on kfreebsd-*, this will cause all PHP 7.0 PECL extensions to FTBFS. And since this is a non-release arch, all we need now is patience. There's really no need to pull the wardrums out of the closet. Cheers, -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server On Mon, Feb 29, 2016, at 14:46, Sergey B Kirpichev wrote: > On Mon, Feb 29, 2016 at 02:28:08PM +0100, Ondřej Surý wrote: > > It's not how important they seem to *me*, but to the release team. > > The FTBFS on non-release archs are not "serious" > > I don't see that here: > https://www.debian.org/Bugs/Developer#severities > > btw, will kfreebsd release arch or not - up to the release team, I > don't think you can decide about this by yourself. Of course, you > can "help" them by ignoring some issues. > > > > Why you break this so easily? > > > (btw, how such archs could get release status if you refuse to assist > > > them?). > > > > This is a breakage that was caused by libtool 2.4.6-0.1 upload. > > ... > > And as you can see in #814271, I fixed this bug within one week when it > > was reported. So please consider your words. > > Maybe. But to check that - package must be in an installable state > on this arch. Otherwise, we can't be sure. > > Ok, you aren't going to reconsider anything, there is no > issue and nothing to do, right? > > ___ > Pkg-php-pecl mailing list > pkg-php-p...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-php-pecl
Re: [Pkg-php-pecl] Bug#816265: Bug#816265: Bug#816265: Bug#816265: php-geoip: FTBFS: libtool: No such file or directory
On Mon, Feb 29, 2016 at 03:56:57PM +0100, Ondřej Surý wrote:
> I simply cannot fix
I'm not about requesting a fix from you. Just about accepting that
there is a problem ("We won't hide problems", remember?). But it seems
you know better how to do the work and I'm just in a wrong place
as a co-maintainer. (bah, after >5 years supporting my php-* packages
or even 7 in this case)
> an architecture that is lagging behind in the builds
> of packages that has already fixed the underlying problem. I simply lack
> the magic powers to modify binary packages by my pure will, so we'll
> have to wait for new builds.
Then why not wait when issue will be _really_ fixed and
only then - close the bugreport?
> And since this is a non-release arch, all we need now is patience.
It will newer be a release arch, with maintainers like you. Apparently,
the Debian project is in good hands.
PS: Dropped myself from uploaders in my php-* packages. Please revoke my
DM upload permissions for them.
Re: [Pkg-php-pecl] Bug#816265: Bug#816265: Bug#816265: Bug#816265: php-geoip: FTBFS: libtool: No such file or directory
> On Mon, Feb 29, 2016, at 14:46, Sergey B Kirpichev wrote: > > On Mon, Feb 29, 2016 at 02:28:08PM +0100, Ondřej Surý wrote: > > > It's not how important they seem to *me*, but to the release team. > > > The FTBFS on non-release archs are not "serious" > > > > I don't see that here: > > https://www.debian.org/Bugs/Developer#severities It pretty clearly says: | serious; is a severe violation of Debian policy (roughly, it violates | a "must" or "required" directive), or, in the package maintainer's or | release manager's opinion, makes the package unsuitable for release. Problems on non-release archs cannot make a package unsuitable for release by definition. It is ok not to know this, but it is not ok to not accept this once you are told about it. > > > > Why you break this so easily? > > > > (btw, how such archs could get release status if you refuse to assist > > > > them?). > > > > > > This is a breakage that was caused by libtool 2.4.6-0.1 upload. > > > ... > > > And as you can see in #814271, I fixed this bug within one week when it > > > was reported. So please consider your words. > > > > Maybe. But to check that - package must be in an installable state > > on this arch. Otherwise, we can't be sure. Right, you can reopen that then. Alternatively, you can rebuild the Build-Depends chain yourself to check if you don't want to wait. But it is not the maintainer's duty to chase this down, unless there is a direct problem with their package. In this case, php7.0 is in state BD-Uninstallable so this is a porter/buildd-admin problem. Michael
Re: [Pkg-fonts-devel] RFP: elusive-icons -- the iconic font and CSS framework
On Mon, Feb 29, 2016 at 10:42 PM, Ghislain Vaillant wrote: > Cc: debian-devel@lists.debian.org, pkg-fonts-de...@lists.alioth.debian.org Please use -- bye, pabs https://wiki.debian.org/PaulWise http://bonedaddy.net/pabs3/ http://wiki.openmoko.org/wiki/User:PaulWise
Re: [Pkg-fonts-devel] RFP: elusive-icons -- the iconic font and CSS framework
On Mon, Feb 29, 2016 at 10:42 PM, Ghislain Vaillant wrote: > Cc: debian-devel@lists.debian.org, pkg-fonts-de...@lists.alioth.debian.org Please use X-Debbugs-CC instead of CC next time: https://www.debian.org/Bugs/Reporting#xcc Apologies for the earlier broken mail. -- bye, pabs https://wiki.debian.org/PaulWise
Re: RE: Debian package on Windows
Hi there, for my occasional development on Windows I use Msys2 which have Arch's pacman package management system ported to Windows and even provide a huge repository of pre-compiled package. It's not APT, but at least a reasonable packaging system and a bash shell on Windows to begin with. ;) Best regards, - Fabian signature.asc Description: This is a digitally signed message part
Re: [Pkg-php-pecl] Bug#816265: Bug#816265: Bug#816265: Bug#816265: php-geoip: FTBFS: libtool: No such file or directory
On Mon, Feb 29, 2016 at 05:22:19PM +0100, Michael Banck wrote: > It pretty clearly says: > > | serious; is a severe violation of Debian policy (roughly, it violates > | a "must" or "required" directive), or, in the package maintainer's or > | release manager's opinion, makes the package unsuitable for release. Yes, _in the package maintainer's_ ... I was package maintainer. Till now, so you shouln't worry about my opinions anymore. Lets end this little lesson. Believe me, some Debian maintainers _can_ read such simple texts. > Right, you can reopen that then. Feel free to do this. Is it a new game?
Re: [Pkg-php-pecl] Bug#816265: Bug#816265: Bug#816265: Bug#816265: php-geoip: FTBFS: libtool: No such file or directory
On 29 February 2016 at 17:57, Sergey B Kirpichev wrote: > On Mon, Feb 29, 2016 at 05:22:19PM +0100, Michael Banck wrote: >> It pretty clearly says: >> >> | serious; is a severe violation of Debian policy (roughly, it violates >> | a "must" or "required" directive), or, in the package maintainer's or >> | release manager's opinion, makes the package unsuitable for release. > > Yes, _in the package maintainer's_ ... I was package maintainer. Till > now, so you shouln't worry about my opinions anymore. Sergey, there are no releases of non-release architectures, hence this argument is unfortunately invalid. > Lets end this little lesson. Believe me, some Debian > maintainers _can_ read such simple texts. > >> Right, you can reopen that then. > > Feel free to do this. Is it a new game? -- Cheers, Andrew
RE: RE: Debian package on Windows
Thanks Fabian, that make sense, we also having a look at this eric -Original Message- From: Fabian Greffrath [mailto:fab...@debian.org] Sent: Monday, February 29, 2016 8:46 AM To: Eric Mittelette Cc: debian-devel@lists.debian.org Subject: Re: RE: Debian package on Windows Hi there, for my occasional development on Windows I use Msys2 which have Arch's pacman package management system ported to Windows and even provide a huge repository of pre-compiled package. It's not APT, but at least a reasonable packaging system and a bash shell on Windows to begin with. ;) Best regards, - Fabian
Re: [Pkg-php-pecl] Bug#816265: Bug#816265: Bug#816265: Bug#816265: php-geoip: FTBFS: libtool: No such file or directory
Hi d-d, I feel this one needs to be clarified as it might sound like those packages were hijacked or something. On Mon, Feb 29, 2016, at 17:57, Sergey B Kirpichev wrote: > Yes, _in the package maintainer's_ ... I was package maintainer. Till > now, so you shouln't worry about my opinions anymore. Those packages had a PECL team as a maintainer and the PHP 7.0 updates were made as a "team" uploads during php5 -> php7.0 transition. And `git blame debian/control` says... php-geoip: f9b5fb9c (Sergey B Kirpichev 2014-01-07 16:48:17 +0400 4) Maintainer: Debian PHP PECL Maintainers php-memcache: c28db1be (Sergey B Kirpichev 2014-01-07 16:48:52 +0400 4) Maintainer: Debian PHP PECL Maintainers php-memcached: 82f6e908 (Sergey B Kirpichev 2014-01-07 16:49:52 +0400 4) Maintainer: Debian PHP PECL Maintainers Cheers, -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
Re: [Pkg-php-pecl] Bug#816265: Bug#816265: Bug#816265: Bug#816265: php-geoip: FTBFS: libtool: No such file or directory
On Mon, Feb 29, 2016 at 06:02:40PM +0100, Andrew Shadura wrote: > there are no releases of non-release architectures AFAIK, there is no defined release archs for stretch yet, so "non-release arch" doesn't make sense before freeze. But the whole point was not about severity. One maintainer clearly "know better" what is a problem and what's not.
Re: [Pkg-php-pecl] Bug#816265: Bug#816265: Bug#816265: Bug#816265: php-geoip: FTBFS: libtool: No such file or directory
On 29 February 2016 at 18:26, Sergey B Kirpichev wrote: > On Mon, Feb 29, 2016 at 06:02:40PM +0100, Andrew Shadura wrote: >> there are no releases of non-release architectures > > AFAIK, there is no defined release archs for stretch yet, so > "non-release arch" doesn't make sense before freeze. > > But the whole point was not about severity. One maintainer > clearly "know better" what is a problem and what's not. In my understanding, a non-release arch stays non-release arch until decided otherwise. Before we had kfreebsd as a release arch it obviously wasn't a release arch, so since it's been removed from release arches bugs affecting it can't be release-critical. -- Cheers, Andrew
Re: [Pkg-php-pecl] Bug#816265: Bug#816265: Bug#816265: Bug#816265: php-geoip: FTBFS: libtool: No such file or directory
Control: reassign -1 php7.0-dev Control: unarchive 814271 Control: forcemerge 814271 -1 Control: affects -1 php-geoip On Mon, 29 Feb 2016, Sergey B Kirpichev wrote: > On Mon, Feb 29, 2016 at 05:22:19PM +0100, Michael Banck wrote: > > It pretty clearly says: > > > > | serious; is a severe violation of Debian policy (roughly, it violates > > | a "must" or "required" directive), or, in the package maintainer's or > > | release manager's opinion, makes the package unsuitable for release. > > Yes, _in the package maintainer's_ ... I was package maintainer. Till > now, so you shouln't worry about my opinions anymore. It would be rather odd to make a bug in a non-release architecture the reason to not release a specific package for all architectures. That said, if the package maintainer feels the particular bug actually should result in the removal of this package from testing for all architectures, then by all means mark it serious. However, in this case, the best thing to do is just to mark the actual bug which broke libtool (#814271) as affecting the other packages, and help the non-release architecture buildds update the versions, fixing whatever bugs are causing them not to be updated. -- Don Armstrong http://www.donarmstrong.com [I]t's true that some of the most terrible things in the world are done by people who think, genuinely think, that they're doing it for the best, especially if there is some god involved. -- Terry Pratchett _Snuff_ p185
Re: [Pkg-php-pecl] Bug#816265: Bug#816265: Bug#816265: Bug#816265: php-geoip: FTBFS: libtool: No such file or directory
Sergey, I think it's about time you stop your repeated ad-hominem attacks against me, and continue this discussion only if you have new technical arguments to support your case. -- Ondřej Surý On 29 Feb 2016 18:27, at 18:27, Sergey B Kirpichev wrote: >On Mon, Feb 29, 2016 at 06:02:40PM +0100, Andrew Shadura wrote: >> there are no releases of non-release architectures > >AFAIK, there is no defined release archs for stretch yet, so >"non-release arch" doesn't make sense before freeze. > >But the whole point was not about severity. One maintainer >clearly "know better" what is a problem and what's not.
Call for testing: glibc 2.19-18+deb8u4
Dear all, I have recently uploaded glibc 2.19-18+deb8u4 to jessie-proposed-updates fixing an old security bug in pt_chown, aka CVE-2013-2207 [1]. This bug has been opened for a lot of time, as the fix which is simply to remove pt_chown has a tendency to break systems [2]. Indeed not using pt_chown requires to mount the devpts with the correct options, and it is relatively easy to break them by mounting the devpts filesystem a second time, for example in a chroot. Recently two alternatives have appeared to overcome this issue, one on the kernel side [3] and on the other side [4]. The glibc patch is present in stretch/sid for more than 2 months and given we haven't received any new bug report, I believe it works correctly. It has therefore been backported to jessie and is now available in jessie proposed updates as version 2.19-18+deb8u4. It would be nice if people can install glibc version 2.19-18+deb8u4 on their system and report any regression compared to 2.19-18+deb8u3 (either by mail or via a bug report). One can try to install the corresponding packages by adding the following entry in apt sources.list: deb http://ftp.debian.org/debian jessie-proposed-updates main Provided there are no regressions, this package will be made available in the next jessie point release. Thanks, Aurelien [1] https://security-tracker.debian.org/tracker/CVE-2013-2207 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806882 [3] https://lkml.org/lkml/2015/12/11/760 [4] https://sourceware.org/git/?p=glibc.git;a=commit;h=77356912e83601fd0240d22fe4d960348b82b5c3 -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
