Re: unattended-upgrade broken

[Bálint Réczey]

Hi Alexandre,

Alexandre Detiste  ezt írta (időpont:
2023. dec. 17., V, 15:37):
>
> How to fix this in an unanttended way ?
>
> (even Salsa seems to have UU installed,
> so maybe impact on infrastructure too)
>
> # unattended-upgrade --verbose
> Traceback (most recent call last):
>   File "/usr/bin/unattended-upgrade", line 83, in 
> import apt_inst
> ImportError: 
> /usr/lib/python3/dist-packages/apt_inst.cpython-311-x86_64-linux-gnu.so:
> undefined symbol: PyAptWarning
> root@brix:~#

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1058657 .
The issue does not seem to be affecting stable and testing, just unstable.

Cheers,
Balint

Bug#1026792: ITP: firebuild -- Automatic build accelerator

[Bálint Réczey]

Package: wnpp
Owner: Balint Reczey 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: firebuild
  Version : 0.2.9
  Upstream Author : i...@firebuild.com
* URL : https://firebuild.com
* License : Firebuild-license
  Programming Lang: C, C++, Python
  Description : Automatic build accelerator

It works by caching the outputs of executed commands and replaying the
results when the same commands are executed with the same parameters
within the same environment.

The commands can be compilation or other build artifact generation
steps, tests, or any command that produces predictable output. The
commands to cache and replay from the cache are determined
automatically based on firebuild's configuration and each command's
and its children's observed behavior.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1003524: O: xxhash -- Extremely fast hash algorithm

[Bálint Réczey]

Package: wnpp
Severity: normal
X-Debbugs-CC: debian-devel@lists.debian.org

Orphaning the package according to Norbert's request:

https://github.com/norbusan/debian-xxhash/pull/7#issuecomment-1009760784

Thanks Norbert for maintaining the package for many years!

Balint

Bug#999697: RFP: popcon-stats-data -- Debian's Popularity Contest statistics

[Bálint Réczey]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-devel@lists.debian.org
Control: merge -1 999677

* Package name: popcon-stats-data
  Version : 0.2024
* URL or Web page : https://popcon.debian.org/
* License : Public Domain (data)
  Description : Debian's Popularity Contest statistics

---

The shipped data would let package managers show the popularity of
packages which could let users make more informed decisions when
choosing between packages to install.

I don't believe this will change the Vim vs. Emacs battle :-), but when I
looked for a DICOM viewer I found a crazy amount of programs of
various quality and knowing which ones were the most widely used would
have sped up picking a good one.

Ideally the stats would be shipped in a format from which APT and
other package managers could efficiently look up the percentage of
Debian systems a particular binary package was installed on.

Cheers,
Balint

Re: Need help with Multi-Arch in systemd

[Bálint Réczey]

Hi Michael,

Michael Biebl  ezt írta (időpont: 2021. júl. 9., P, 22:42):
>
> Hi Guillem,
>
> thanks for your feedback
>
> Am 09.07.21 um 13:46 schrieb Guillem Jover:
> > If the private library has no backwards or forward compatibility (due
> > to the SONAME used) the time window where the library does not match
> > the expectations of the stuff linked to it might indeed be too big.
>
> The libsystemd-shared library is considered an implementation detail and
> indeed has no guaranteed backwards or forward compatibility.
> The soname is bumped when the first rc1 release is made (e.g v249-rc1 →
> libsystemd-shared-249.so) and there might even be incompatible changes
> between the rc1 and the final release.
>
> > But the reported bug is just a symptom of a bigger issue. This problem
> > already exists for any of the other binary packages built against this
> > private shared library, there's a time-window where they will not work
> > if the installation gets interrupted or fails, compared with public
> > shared libraries.
>
> This observation is correct I'd say. Currently we have the following
> split-off binary packages which ship binaries that link against
> libsystemd-shared:
>
> systemd-container (4 binaries in $PATH, 7 services, 11 total)
> systemd-coredump (1 binary in $PATH, 1 service, 2 total)
> systemd-journal-remote (3 services, 3 total)
> systemd-timesyncd (1 service, 1 total)
>
> (I'll exclude systemd-tests, as this is a special case)
>
> The main difference here, is that none of those binaries is really
> critical for the runtime of the system.
> An unbootable system though is one of the worst things that can happen.
> Which is why I'm really reluctant to split off libsystemd-shared from
> systemd and hopefully also explains why in general I'm not super keen on
> chopping up src:systemd unnecessarily.
>
> > This implies to me the correct solution is a name-versioned package,
> > even though that seems cumbersome given our current archive handling
> > practices this is IMO the only correct solution.
>
> A name-versioned package would certainly be better then an unversioned
> libsystemd-shared package. It still would make PID 1 a bit more brittle
> though (see e.g. my comment regard rc releases).
> It would also need patching of the build system, to override the rpath,
> which would have to be multi-arch aware.
>
> $ find . -name meson.build | xargs grep rpath | wc -l
> 123
>
> This would be a significant patch with a lot of ongoing churn and
> maintenance effort. I'm not sure if I'm willing or even able to do that.

IMO what Guillem recommends, i.e. the name-versioned libsystemd
package with versioned shared library name is still the cleanest and
so far the only reasonably reliable solution. IMO going through NEW in
every few months could be an acceptable cost especially since I was
quite happy with the pace at which NEW is processed recently. I don't
maintain systemd in Ubuntu anymore, but if I were, I'd be happy to
accept this increased maintenance burden for the sake of having a
clean solution for the Multi-Arch problem. If release candidates will
be uploaded only to experimental then the incompatible changes won't
cause problems. Even if RC-s are uploaded to unstable and a rarely
occurring incompatible change takes place then the library package
name can be bumped again.
After we discussed this topic on #debian devel on 2020-05-05 I even
started implementing the solution but did not finish it because it was
not an important problem from Ubuntu's POV.

I think the rpath usage search counted a lot of hits which don't have
to be changed and maybe upstream would be willing to accept the patch.

Cheers,
Balint

Re: Disabling automatic upgrades on Sid by default?

[Bálint Réczey]

Hi Sean,

Sean Whitton  ezt írta (időpont: 2020. dec.
28., H, 0:05):
>
> Hello,
>
> On Sun 27 Dec 2020 at 08:11AM GMT, Paul Wise wrote:
>
> > I think Debian stable users should enable automatic upgrades (IIRC
> > that is the case now). Debian unstable/testing users should probably
> > only enable safe upgrades that don't remove packages.
>
> I'm pretty sure it's not default because the security team do not
> consider unattended-upgrades sufficiently robust.  I'm sorry for not
> going ahead and verifying but I thought it should be mentioned.

If that's the case (i.e. security team having concerns) I'd like to
learn about them (wearing my unattended-upgrades maintainer hat).
The version in testing is pretty solid IMO, but there is still enough
time for fixes before the next stable release.

Also please note that unattended-upgrades does not perform upgrades
which include removals. The original report was about Gnome's upgrade
mechanism as I understand it, which is disabled in Ubuntu for several
reason including the lack of safety measures applied in
unattended-upgrades:
https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1775226

Cheers,
Balint

>
> --
> Sean Whitton

RFA: several packages around Kodi

[Bálint Réczey]

Hi All,

These packages are maintained officially by the Multimedia Team, but
I'm the only uploader for them:

crystalhd
forked-daapd
kodi-pvr-argustv
kodi-pvr-dvbviewer
kodi-pvr-hdhomerun
kodi-pvr-iptvsimple
kodi-pvr-mediaportal-tvserver
kodi-pvr-mythtv
kodi-pvr-nextpvr
kodi-pvr-njoy
kodi-pvr-vuplus
kodi-pvr-wmc
libshairport

The Kodi plugins will need to be updated for the new Kodi release, but
despite the kodi package being ready for upload since March I could
not upload it because build dependencies are not available yet in the
archive. (While I pushed them as far as I could as a DD.)

In general the packages are in a good shape and I'd like to find
people who would step up as uploaders replacing me. I have already
written an RFA email [1] to the team mailing list but got no response,
maybe there are people in this wider audience who are interested in
the packages listed above.

Cheers,
Balint

PS: I added a comment to #895917 before sending this email to
debian-devel, see [2].

[1] https://lists.debian.org/debian-multimedia/2019/01/msg00013.html
[2] https://balintreczey.hu/blog/my-debian-devel-pledge

Re: Bits from the DPL (August 2019)

[Bálint Réczey]

Hi,

Sam Hartman  ezt írta (időpont: 2019. szept. 18.,
Sze, 22:47):
>
>
> Dear Debian:
>
...
> Init System Diversity
> =
..
> Honestly, I'm not entirely sure how to move forward.  Perhaps it's just
> that I haven't talked to someone I need to.  Perhaps someone will read
> this, and let me know that if I'd included them, we could get the right
> skills and authority engaged.  I'll feel embarrassed and we'll all move
> on if that's the case.  But I think we may be approaching a point where
> we need to poll the project--to have a GR and ask ourselves how
> committed we are to the different parts of this init diversity
> discussion.  Reaffirming our support for sysvinit and elogind would be
> one of the options in any such GR.  If that option passed, we'd expect
> all the maintainers involved to work together or to appoint and empower
> people who could work on this issue.  It would be fine for maintainers
> not to be involved so long as they did not block progress.  And of
> course we would hold the discussions to the highest standards of
> respect.
>
> Things may have changed since our last GR on the issue.  There are 1033
> non-overridden instances of lintian detecting a service unit without an
> init.d script [7].  The false positive rate seems high especially for
> packages that break their systemd integration.  There's been discussion
> on debian-devel about moving to using service units as the default
> rather than init scripts [8].
>
> So perhaps sysvinit and init scripts have had their chance and it is
> time to move on.  We could move away from init scripts as the default
> representation.  We could stop caring about sysvinit (which isn't quite
> the same thing but is related).  That would leave non-linux ports in an
> unfortunate position.  But right now there are no non-linux ports in the
> main archive.  So perhaps we don't even care about that.  Again, a
> change, but a change that we can ask ourselves if we are ready to make.

I would like to just remind ourselves that in WSL and Docker
containers systemd is not running as the init system and systemd
services can't be started easily but init.d scripts can be.
There is very significant interest from users to run services easily
in those and other similar environments and dropping init.d scripts
would make their life much harder.
I do see that maintaining init.d scripts is work but speaking for
myself I'm happy to maintain them
in my packages even when I use those packages only with systems running systemd.

My two cents is that in init system diversity decisions please
consider the environments where none of our packaged init systems are
running, but which are perfectly capable to run useful services.

Cheers,
Balint

...
>   [7]:
>   
> https://lintian.debian.org/tags/package-supports-alternative-init-but-no-init.d-script.html
>   [8]: 
> https://lists.debian.org/msgid-search/87h86qvh1q@proton.d.airelinux.org
...

PS: I marked #856268 as wontfix before sending this email to debian-devel.
https://balintreczey.hu/blog/my-debian-devel-pledge

Re: Suite name for security updates changing with Debian 11 "bullseye"

[Bálint Réczey]

Hi Ansgar,

Ansgar Burchardt  ezt írta (időpont: 2019. júl.
11., Cs, 22:02):
>
> Hi,
>
> over the last years we had people getting confused over -updates
> (recommended updates) and /updates (security updates).  Starting
> with Debian 11 "bullseye" we have therefore renamed the suite including
> the security updates to -security.
>
> An entry in sources.list should look like
>
>   deb http://security.debian.org/debian-security bullseye-security main
>
> For previous releases the name will not change.

Since we are at it we could also rename -proposed-updates to
-proposed to simplify the name a bit and also become in sync
with Ubuntu.

The following logic is probably duplicated in other software, too:
https://github.com/mvo5/unattended-upgrades/blob/1.13/debian/tests/common-functions#L47

Cheers,
Balint

---
I closed #631715 before sending this email to debian-devel.
https://balintreczey.hu/blog/my-debian-devel-pledge

Bug#912303: RFA: libopenhmd

[Bálint Réczey]

Package: wnpp
Severity: normal
X-Debbugs-CC: debian-devel@lists.debian.org

Hi,

Due to trying to focus on other packages I'm looking for someone to
adopt this package.
It does not need a lot of attention and is in a good shape, I just did
not start the project I wanted to use it for.

Thanks,
Balint

Re: Auto-update for sid? Auto-backport?

[Bálint Réczey]

Hi Guido,

2017-11-24 12:48 GMT+01:00 Guido Günther :
> Hi,
> On Fri, Nov 17, 2017 at 04:31:43PM +0100, Guido Günther wrote:
>> Hi,
>> On Wed, Nov 15, 2017 at 04:43:17PM +0100, Steffen Möller wrote:
>> > Hello,
>> >
>> > my QA page or our blend's task page (like
>> > https://blends.debian.org/med/tasks/bio-ngs) regularly informs me about
>> > updates that should be performed to packages I alone maintain or (more
>> > likely) with the help of my blend. The updates are often (but now
>> > always, admittedly) easy to do.
>> >
>> > I would really like to see updates performed in some automated fashion.
>> > Maybe into a different section of Debian like sid-auto? The problem with
>> > that obviously is the missing scrutiny by the human maintainer, so it
>> > cannot go straight into sid. Or can it? Maybe with an auto-created bug
>> > report against the package so it does not auto-migrate into testing?
>>
>> What I have started to do is having jobs that run once a day uscan,
>> rebase patches, build in pbuilder, run autopkgtests via pbuilder's
>> autopkgtest hook[1] (to be put into a Jenkins instance).
>>
>> That's about 99% of the busy work since I know in advance which packages
>> will need work (because patches no longer apply, tests fail or lintian
>> reports errors) while others can be uploaded right away after more
>> manual testing (if they don't have excessive test suites). Would that
>> help already? if so we could look into making this more usable to
>> others.
>
> I've cleaned stuff up a bit and moved some of the (smaller) jobs to a
> public instance:
>
> http://autoff.sigxcpu.org
>
> and dumped the ansible to setup jenkins and the jobs here:
>
> http://github.com/agx/debautoff
> http://github.com/agx/debautoff-projects
>
> (Autopkgtests are currently disabled to not make the vm explode). If
> this make sense for others as well it needs to be moved to a bigger
> instance (maybe integrated with jenkins.debian.net)?

Thanks! I believe at some point such service will need much bigger machines. :-)

I was thinking about automating the repetitive tasks, too for some time
but could not find time to implement fully what I wanted to share as an
initial release.
I just uploaded a prototype/skeleton of the idea here:
https://anonscm.debian.org/cgit/collab-maint/debian-dad.git

Instead of starting with the service concept I went with the distributed
usage model to let everyone play with the tool easily even with
private packages.

The idea was starting from a known source package name and helping
the maintainer as much as possible in an automated manner and providing
the changes in a git repository nicely separated commit by commit.

The set of packages which can be updated easily includes the ones
without any packaging repository and the the update is not limited to
updating to latest upstream and testing the result. There are many minor
changes which can be easily applied like fixing smaller problems
already reported by Lintian and as an example I already implemented
updating symbols files.

Please take a look and if you like the concept I'll go ahead with an ITP
and welcome contributions.
I don't plan sticking to one particular packaging repository format, for
example I plan adding support for tracking upstream branches
commit-by-commit with gbp but Subversion repository support will most
likely exist only via git-svn.

Cheers,
Balint


>
> Cheers,
>  -- Guido
>
>>
>> > A similar situation I see with backports. Most commonly all that is
>> > needed is a recompilation. Would an automation of that process be
>> > acceptable? Would it be acceptable for packages that offer some means of
>> > automated testing and are in backports already?
>> >
>> > Many thanks for your opinions
>> >
>> > Steffen
>> >
>>
>> [1]: /usr/share/doc/git-buildpackage/examples/gbp-try-ff
>>

--
I fixed #875980 in git before sending this email to debian-devel.
http://balintreczey.hu/blog/my-debian-devel-pledge
Actually I fixed it using 'dad update' and tested the results manually. :-)

Re: [RFC] The PIE unholy mess

[Bálint Réczey]

Hi Emilio,

2017-01-18 18:44 GMT+01:00 Emilio Pozuelo Monfort :
> On 18/01/17 18:23, Matthias Klose wrote:
>> At this point, I would prefer to revert the PIE changes for the release and
>> discuss these after the release with all parties involved.
>
> It's not the time to revert that, thanks.

I think Matthias meant reverting the changes to dpkg passing -spec to gcc,
and not all the PIE related changes - this would make sense and fix
several bugs IMO.

Cheers,
Balint

--
I have marked #816223 as fixed and closed it before sending this email
to debian-devel.
http://balintreczey.hu/blog/my-debian-devel-pledge

Re: [RFC] The PIE unholy mess

[Bálint Réczey]

 Hi,

2017-01-18 4:34 GMT+01:00 Guillem Jover :
> Hi!
>
> I'd like to get some feedback from porters and package maintainers,
> given that this affects at least both groups. Some background first.
>
> One of the reasons PIE has in the past not been enabled by default in
> dpkg-buildflags, is because it introduced some slowness on some arches,
> although this has somewhat changed recently. But also because
> unconditionally setting it, breaks at least PIC builds. So PIE got
> enabled recently by default in gcc, as it could easily control when it
> is relevant. Although this has been done only for release architectures.
>
> At about the same time this was being considered, I realized that dpkg
> could enable this "safely" by using gcc specs files. But this is in
> any case also required to be able to disable PIE when it is implicitly
> enabled by default in gcc. So we'll need specs files no matter what,
> at least for now.
>
> While adapting dpkg-buildflags to cover for the new gcc defaults, I
> unintentionally enabled PIE by default on all architectures, and when
> I noticed, it seemed to make sense to leave it like that, because:
>
>   * All previous build flags from dpkg-buildflags have always been
> enabled globally and only blacklisted completely when they have
> been non-functional.
>   * It's a more consistent interface for packages, as they get built
> with the same flags everywhere. Otherwise we'd get PIE enabled by
> default in release arches, disabled by default elsewhere, and
> enabled or disabled depending on the package requesting so.
>   * It will mean that PIE coverage reporting will be shadowed in
> lintian, because the tags only cover i386 and amd64, so maintainers
> will probably stop enabling them globally.
>
> Matthias Klose recently filed an unclear report (#848129) on dpkg-dev
> requesting to not enable PIE globally from dpkg-buildflags, and pretty
> much immediately added a patch into gcc [P] to ignore dpkg-buildflags
> PIE -specs flags if DEB_BUILD_OPTIONS or DEB_BUILD_MAINT_OPTIONS did
> not enable PIE explicitly (I only fully understood the request after
> seeing the gcc patch).
>
>   [P] 
> 
>
> Besides this being completely broken, as DEB_BUILD_MAINT_OPTIONS
> does not even need to be exported from debian/rules, nor from the
> dpkg architecture.mk fragment, or when dpkg-buildflags is used with its
> --export=configure or --export=cmdline. It's also a layer violation.
> It also breaks unrelated stuff as now gcc emits notes when it thinks
> the -specs option should not be passed. And while I could certainly
> have started an arms-race by adding counter-measures by randomizing
> the filenames or something similarly ugly, that'd be pretty much silly
> and childish.
>
> For better or worse, this does not affect the release architectures,
> so by extension it should not affect the release, but it still sucks.
>
> So, I'd like to know how people feel about the requested interface
> (i.e. not enabling PIE globally from dpkg-buildflags). If there's
> consensus that porters and maintainers want that, I'll just change
> dpkg-buildflags to do this, even though I think it's a very
> suboptiomal behavior.

To detail the requested interface (requested originally in #835149 and
then in #848129 currently) is:

* Enable PIE in GCC on a set of architectures (GCC-PIE-ARCH-es)
* On every GCC-PIE-ARCH make dpkg-buildflags' "-pie" a noop, "+pie"
  still adds pie flag to compiler flags
  ("hardening=+all,-pie" would pass no PIE related flag to compiler)
* On every non GCC-PIE-ARCH leave dpkg-buildflags work as they did
before changing GCC's defaults
* Don't pass -specs from dpkg in any case

>
> Alternatively, porters could as well request PIE be enabled by default
> in gcc on their port, which could make this also globally enabled.

Enabling PIE for a specific port would involve enabling it in GCC first then
adapting dpkg in the next step.


Cheers,
Balint

Re: Test instance of our infrastructure

[Bálint Réczey]

Hi,

2016-12-08 23:24 GMT+01:00 Paul Wise :
> On Mon, Nov 28, 2016 at 8:04 PM, Ian Jackson wrote:
>
>> Should we not have public test instances of all these things ?
>
> If this will increase the bus factor of Debian services, that would be great.
> If this will just be a time sink for the people involved, that would
> be less great.
> On balance, it sounds like the vagrant suggestion is the best trade-off here.

DSA Team already relies on puppet for setting up new machines [1].

Migrating all the configuration to puppet could help DSA's work and would
also enable setting up private/public test instances in an automated way.

The puppet packages seem to be in good shape in Debian and adding
a few more modules could cover most of DSA's needs. I would happily
contribute by packaging a few modules.

Providing a puppet module could be a criterion for accepting new services,
but I'm not part of the DSA team, this is just a suggestion. :-)

Cheers,
Balint

[1] https://dsa.debian.org/howto/new-machine/

Re: Migration despite an RC bug?

[Bálint Réczey]

Hi,

2016-12-30 12:53 GMT+01:00 Guillem Jover :
> Hi!
>
> On Fri, 2016-12-30 at 09:25:20 +0100, Emilio Pozuelo Monfort wrote:
>> On 29/12/16 23:36, Christoph Biedl wrote:
>> > Emilio Pozuelo Monfort wrote...
>> >> Unforunately, the BTS exported a broken/incomplete RC bug list, and 
>> >> britney used
>> >> that and didn't see that some packages had an RC bug, so it allowed them 
>> >> to migrate.
>
>> > please rather focus on restoring the correct state. Installations
>> > running testing already might have got packages they shouldn't see.
>>
>> We thought about rolling back to the previous state, but that means testing
>> users who have already upgraded would need to manually downgrade... which is 
>> not
>> good.
>
> Yeah, any solution at this point will have serious downsides. :/

While this is not a solution but user-tagging the RC bugs which would
have prevented the migration but were ignored could help quickly
reviewing the packages which are affected.

Cheers,
Balint

>
>> So we may just wait for the auto-removal hinter to do its job for
>> non-key-packages, and for the rest to be fixed or manually downgraded, or
>> whatever other solution...
>
> I hope this does not trigger a storm of unnecessarily epoch'ed uploads. :(
>
> Thanks,
> Guillem
>

Re: [RFC] Enabling bindnow by default in dpkg-buildflags?

[Bálint Réczey]

2016-12-19 14:58 GMT+01:00 Julien Cristau <jcris...@debian.org>:
> On 12/19/2016 11:37 AM, Bálint Réczey wrote:
>> Thanks. If I could perform the autopkgtest run with bindnow this year would 
>> it
>> be convincing enough given only a small amount of breakages to enable
>> bindnow early in January?
>>
> I thought I was clear earlier.  No, enabling bindnow globally is
> something which, if it's going to happen (it's not clear to me that's a
> good idea), can only happen at the beginning of the release cycle, not
> when we're getting close to freeze, let alone during freeze.

OK.

Re: [RFC] Enabling bindnow by default in dpkg-buildflags?

[Bálint Réczey]

Hi Guillem,

2016-12-19 1:34 GMT+01:00 Guillem Jover <guil...@debian.org>:
> On Sat, 2016-12-17 at 09:20:40 +0100, Bálint Réczey wrote:
>> 2016-12-17 3:14 GMT+01:00 Guillem Jover <guil...@debian.org>:
>> > On Wed, 2016-12-14 at 14:05:44 +0100, Bálint Réczey wrote:
>> >> 2016-12-13 9:29 GMT+01:00 Bálint Réczey <bal...@balintreczey.hu>:
>> >> > 2016-11-27 23:11 GMT+01:00 Bálint Réczey <bal...@balintreczey.hu>:
>> >> >> Lucas already performed the archive-wide rebuild with bindnow
>> >> >> enabled by dpkg and we have not observed breakages specific to
>> >> >> bindnow. IMO this is mostly due to packages already disabling
>> >> >> bindnow through dpkg-buildflags.
>> >
>> > But you didn't do the requested archive-wide autopkgtest run (because
>> > "it was hard"), and even though the coverage is not great it would
>> > be better than nothing. Requested in this case because bindnow changes
>> > the *run-time* behavior, which is not visible or noticable in normal
>> > circumstances by just *building* packages.
>>
>> I'm surprised you raise the autopkgtest run question.
>
> I mentioned it explicitly on a private mail Lucas sent to me, Niels and
> Kurt, which prompted me to update the dpkg FAQ, and then again a week
> after in <https://lists.debian.org/debian-devel/2016/08/msg00384.html>.
>
> In addition on that private conversation I also mentioned this:
>
>   And this still leaves many packages that might fail at run-time (not
>   to mention the startup slow down), so this option seems potentially
>   dangerous to enable globally. OTOH at least both Gentoo and Fedora
>   seem to have done so:
>
> <https://wiki.gentoo.org/wiki/Hardened/Toolchain>
> <https://fedoraproject.org/wiki/Changes/Harden_All_Packages>
>
>   And some known issues:
>
> <http://www.zsh.org/mla/workers/2015/msg02981.html>
> <https://bugzilla.redhat.com/show_bug.cgi?id=1199775>
> The Gentoo wiki also mentions that X is not happy about this, but
> I'm not sure how current that is.
>
> Which then updated <https://wiki.debian.org/Hardening> with some of
> those relevant links, but maybe that was too subtle.

Note that you did not list autopkgtest as  a strong requirement:

 https://lists.debian.org/debian-devel/2016/08/msg00384.html
...
 From dpkg PoV enabling both, would at least require a full-archive
 rebuild, for bindnow ideally also a full autopkgtest run (as the
 updated dpkg FAQ states now, after Lucas Nussbaum approached me some
 weeks ago mentioning he was willing to do such archive-wide rebuild).
...

Note the word "ideally".
Those emails were the exact reasons why I asked a proper clarification on
10 October to be able to at least give autopkgtest a try in time:
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=835146#12

>
>> I asked for clarification then because the on 13 Aug you added the
>> following line to dpkg FAQ which does not seem to be a strong
>> requirement:
>> * For flags that change run-time semantics, ideally an additional run
>> of the autopkgtest for packages that ship them (although this cannot
>> be deemed conclusive as our coverage is not great yet).
>> ( https://wiki.debian.org/Teams/Dpkg/FAQ?action=diff=28=29 )
>
> It certainly is not going to be conclusive as a way to verify it correct,
> as even with no failures would not mean there's no potential problems;
> this would merely apply the principle of "falsificationism" to the
> proposal. So it might be helpful as an additional data point to try to
> gauge the possible fallout, but not as a way to say "everything ok, no
> problems found". Which I guess does not play in your favor, I'll
> update the FAQ to makes this more clear.

I agree with that.

>
>> I would like to kindly ask the Release Team to share its position on the
>> bindnow question since Guillem don't seem to let this move forward
>> without that.
>
> BTW, in contrast to PIE, to be able to use bindnow globally on your
> system you don't even have to recompile anything. You can simply add
> LD_BIND_NOW=1 in your /etc/environment for example (man ld.so(8)).

It may work for a some systems but this would also set bindnow for
programs not working properly with bindnow in contrast to enabling bindnow
in dpkg globally and disabling it per problematic package.


>
> Also according to the release schedule, it appears to me people still
> have up to 10 days before 2017-02-05 to enable bindnow in their
> packages?

True, I have updated my blog post with that later date. Thanks for
pointing that out.

>
> And in any case, I've written down to propose enabling this at the
> beginning of the dpkg 1.19.x release cycle (which will match the buster
> release cycle) in <https://wiki.debian.org/Teams/Dpkg/RoadMap>.

Thanks. If I could perform the autopkgtest run with bindnow this year would it
be convincing enough given only a small amount of breakages to enable
bindnow early in January?

Thanks,
Balint

>
> Regards,
> Guillem

Re: [RFC] Enabling bindnow by default in dpkg-buildflags?

[Bálint Réczey]

Hi,

2016-12-17 10:17 GMT+01:00 Julien Cristau <jcris...@debian.org>:
> On Sat, Dec 17, 2016 at 09:20:40 +0100, Bálint Réczey wrote:
>
>> >> >> Considering that we are already in the transition freeze I suggest
>> >> >> going with enabling bindnow for all architectures in dpkg and
>> >> >> for Stretch+1 the responsibility of setting some hardening flags
>> >> >> could be transferred to gcc.
>> >> >> IMO this is not a transition because the change does not affect
>> >> >> package interdependencies.
>> >> >
>> >> > Is there any update on this?
>> >
>> > I've not seen any reply from the release team, no. And as explicitly
>> > mentioned before multiple times now, this has the potential to impact
>> > the release by introducing subtle and possibly hard to spot errors at
>> > *run-time*, which might be triggered by simple a upload or a binNMU w/o
>> > the maintainer being in the loop and knowing they have enabled bindnow.
>> > So I want the release team to be involved in ACKing this potentially
>> > release breaking change.
>>
>> I would like to kindly ask the Release Team to share its position on the
>> bindnow question since Guillem don't seem to let this move forward
>> without that.
>>
> That is very much not happening for stretch.

This is a bit terse and a bit late but DD-s are still free to enable
bindnow per package in the next 7 days.

Affected packages:
https://lintian.debian.org/tags/hardening-no-bindnow.html

Thanks,
Balint

Re: [RFC] Enabling bindnow by default in dpkg-buildflags?

[Bálint Réczey]

Hi Guillem,

2016-12-17 3:14 GMT+01:00 Guillem Jover <guil...@debian.org>:
> On Wed, 2016-12-14 at 14:05:44 +0100, Bálint Réczey wrote:
>> 2016-12-13 9:29 GMT+01:00 Bálint Réczey <bal...@balintreczey.hu>:
>> > 2016-11-27 23:11 GMT+01:00 Bálint Réczey <bal...@balintreczey.hu>:
>> >> 2016-11-23 2:30 GMT+01:00 Guillem Jover <guil...@debian.org>:
>> >>> My mine concern is and has always been that bindnow changes the
>> >>> run-time behavior (instead of the build-time one) and could break
>> >>> things such as dlopen() on shared libraries or plugins and similar.
>> >>> And detecting problems becomes harder, and reverting this change
>> >>> iff we notice that it breaks too much might imply rebuilding an
>> >>> unspecified number of packages. So in a way it feels kind of like
>> >>> a transition?
>> >>>
>> >>> OTOH Ubuntu seems to have been enabling not only PIE and bindnow by
>> >>> default in gcc for a long time, but also relro, stack-protector and
>> >>> fortify. Which would seem to imply this might not break that much?
>> >>> (I'm not sure why we are not enabling all those in gcc in Debian
>> >>> too, but that's probably a different conversation to have if at all.)
>> >>
>> >> Lucas already performed the archive-wide rebuild with bindnow
>> >> enabled by dpkg and we have not observed breakages specific to
>> >> bindnow. IMO this is mostly due to packages already disabling
>> >> bindnow through dpkg-buildflags.
>
> But you didn't do the requested archive-wide autopkgtest run (because
> "it was hard"), and even though the coverage is not great it would
> be better than nothing. Requested in this case because bindnow changes
> the *run-time* behavior, which is not visible or noticable in normal
> circumstances by just *building* packages.

I'm surprised you raise the autopkgtest run question.

Have you missed my email about this?
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=835146#12

2016-10-10 14:06 GMT+02:00 Balint Reczey <bal...@balintreczey.hu>:
> Dear Guillem,
>
> On Tue, 23 Aug 2016 00:14:25 +0200 Balint Reczey <bal...@balintreczey.hu> 
> wrote:
> ...
>> Dear Guillem,
>>
>> As a continuation of the discussions [1][2] on debian-devel I'm
>> attaching the simple patch that implements enabling the bindnow
>> hardening flags.
>>
>> I'm continuing with the rebuild/autopkgtest tests according to
>> the Dpkg FAQ, hence the moreinfo tag.
>
> The rebuild (with PIE and bindnow enabled) resulted ~1000 FTBFS
> cases from which all seem to be related to enabling PIE by
> default [3].
>
> ~70 of the filed related bugs [4] are still open.
>
> Since the rebuild was run with tests enabled this seems to be a
> good indication that we can expect very few breakages from
> enabling bindnow by default.
>
> Running autopkgtest would need more work as AFAIK there is no
> automated method for doing it like rebuilds [5].
>
> I'm wondering if you find the autopkgtest round necessary for
> this change.

You never answered, but I thought you read the whole bug history.

I asked for clarification then because the on 13 Aug you added the
following line to dpkg FAQ which does not seem to be a strong
requirement:
* For flags that change run-time semantics, ideally an additional run
of the autopkgtest for packages that ship them (although this cannot
be deemed conclusive as our coverage is not great yet).
( https://wiki.debian.org/Teams/Dpkg/FAQ?action=diff=28=29 )

I would say it would have been really nice to provide a feedback about
your position two months ago because I could set up something to run
the aforementioned autopkgtest run in addition to the archive wide
rebuild which included all build-time tests, but you can still add your
answer to the bug report.

>
>> >> Considering that we are already in the transition freeze I suggest
>> >> going with enabling bindnow for all architectures in dpkg and
>> >> for Stretch+1 the responsibility of setting some hardening flags
>> >> could be transferred to gcc.
>> >> IMO this is not a transition because the change does not affect
>> >> package interdependencies.
>> >
>> > Is there any update on this?
>
> I've not seen any reply from the release team, no. And as explicitly
> mentioned before multiple times now, this has the potential to impact
> the release by introducing subtle and possibly hard to spot errors at
> *run-time*, which might be triggered by simple a upload or a binNMU w/o
> the maintainer being in 

Re: [RFC] Enabling bindnow by default in dpkg-buildflags?

[Bálint Réczey]

Hi All,

2016-12-13 9:29 GMT+01:00 Bálint Réczey <bal...@balintreczey.hu>:
> Hi Guillem,
>
> 2016-11-27 23:11 GMT+01:00 Bálint Réczey <bal...@balintreczey.hu>:
>> Hi Guillem,
>>
>> 2016-11-23 2:30 GMT+01:00 Guillem Jover <guil...@debian.org>:
>>> Hi!
>>>
>>> This was discussed relatively recently, but it was not entirely clear
>>> to me what was the conclusion, if there was any(?), about enabling
>>> bindnow by default.
>>>
>>> And although this got enabled by default in gcc-6 6.2.0-7 when PIE
>>> also got enabled, it seems it got disabled in 6.2.0-10 when I pointed
>>> out that enabling bindnow in gcc w/o enabling relro too didn't seem to
>>> make much sense, but then I didn't notice any rationale for the
>>> reversion, instead of say enabling relro too.
>>
>> GCC enabled bindnow only for architectures which also enabled
>> PIE by default, but unlike PIE there were no architecture-specific
>> objections against enabling bindnow.
>>
>> I think talking to Matthias (@Matthias: talking to Guillem) and
>> reaching a consensus would be badly needed for the project.
>>
>>>
>>>
>>> My mine concern is and has always been that bindnow changes the
>>> run-time behavior (instead of the build-time one) and could break
>>> things such as dlopen() on shared libraries or plugins and similar.
>>> And detecting problems becomes harder, and reverting this change
>>> iff we notice that it breaks too much might imply rebuilding an
>>> unspecified number of packages. So in a way it feels kind of like
>>> a transition?
>>>
>>> OTOH Ubuntu seems to have been enabling not only PIE and bindnow by
>>> default in gcc for a long time, but also relro, stack-protector and
>>> fortify. Which would seem to imply this might not break that much?
>>> (I'm not sure why we are not enabling all those in gcc in Debian
>>> too, but that's probably a different conversation to have if at all.)
>>
>> Lucas already performed the archive-wide rebuild with bindnow
>> enabled by dpkg and we have not observed breakages specific to
>> bindnow. IMO this is mostly due to packages already disabling
>> bindnow through dpkg-buildflags.
>>
>> Considering that we are already in the transition freeze I suggest
>> going with enabling bindnow for all architectures in dpkg and
>> for Stretch+1 the responsibility of setting some hardening flags
>> could be transferred to gcc.
>> IMO this is not a transition because the change does not affect
>> package interdependencies.
>
> Is there any update on this?
>
> We are running out of time...

I have uploaded a dpkg NMU with bindnow enabled to DELAYED/10
according to current NMU rules. If the Release Team increases the
severity of #835146 it can reach unstable earlier.

Cheers,
Balint

>>>
>>> So at this point, I guess I still have concerns, but only very mild
>>> ones, and would not mind one way or another, but would like input
>>> from at least the release team, because I don't feel like possibly
>>> deciding on this on my own, even more at this stage of the release.
>>>
>>> Thanks,
>>> Guillem

Re: [RFC] Enabling bindnow by default in dpkg-buildflags?

[Bálint Réczey]

Hi Guillem,

2016-11-27 23:11 GMT+01:00 Bálint Réczey <bal...@balintreczey.hu>:
> Hi Guillem,
>
> 2016-11-23 2:30 GMT+01:00 Guillem Jover <guil...@debian.org>:
>> Hi!
>>
>> This was discussed relatively recently, but it was not entirely clear
>> to me what was the conclusion, if there was any(?), about enabling
>> bindnow by default.
>>
>> And although this got enabled by default in gcc-6 6.2.0-7 when PIE
>> also got enabled, it seems it got disabled in 6.2.0-10 when I pointed
>> out that enabling bindnow in gcc w/o enabling relro too didn't seem to
>> make much sense, but then I didn't notice any rationale for the
>> reversion, instead of say enabling relro too.
>
> GCC enabled bindnow only for architectures which also enabled
> PIE by default, but unlike PIE there were no architecture-specific
> objections against enabling bindnow.
>
> I think talking to Matthias (@Matthias: talking to Guillem) and
> reaching a consensus would be badly needed for the project.
>
>>
>>
>> My mine concern is and has always been that bindnow changes the
>> run-time behavior (instead of the build-time one) and could break
>> things such as dlopen() on shared libraries or plugins and similar.
>> And detecting problems becomes harder, and reverting this change
>> iff we notice that it breaks too much might imply rebuilding an
>> unspecified number of packages. So in a way it feels kind of like
>> a transition?
>>
>> OTOH Ubuntu seems to have been enabling not only PIE and bindnow by
>> default in gcc for a long time, but also relro, stack-protector and
>> fortify. Which would seem to imply this might not break that much?
>> (I'm not sure why we are not enabling all those in gcc in Debian
>> too, but that's probably a different conversation to have if at all.)
>
> Lucas already performed the archive-wide rebuild with bindnow
> enabled by dpkg and we have not observed breakages specific to
> bindnow. IMO this is mostly due to packages already disabling
> bindnow through dpkg-buildflags.
>
> Considering that we are already in the transition freeze I suggest
> going with enabling bindnow for all architectures in dpkg and
> for Stretch+1 the responsibility of setting some hardening flags
> could be transferred to gcc.
> IMO this is not a transition because the change does not affect
> package interdependencies.

Is there any update on this?

We are running out of time...

Cheers,
Balint

>
> Cheers,
> Balint
>
>>
>>
>> So at this point, I guess I still have concerns, but only very mild
>> ones, and would not mind one way or another, but would like input
>> from at least the release team, because I don't feel like possibly
>> deciding on this on my own, even more at this stage of the release.
>>
>> Thanks,
>> Guillem

Re: Let's stop using CVS for debian.org website

[Bálint Réczey]

Hi Sean,

2016-11-28 23:23 GMT+01:00 Sean Whitton <spwhit...@spwhitton.name>:
> Hello Bálint,
>
> On Mon, Nov 28, 2016 at 06:33:34PM +0100, Bálint Réczey wrote:
>> It is not a subtree clone, but the result is practically the same
>
> It wouldn't permit making new commits, though.

This is true, those who don't have good access can't make new commits
to the remote repository by pushing changes, but they can make the
"subtree clone" a local repository and send the patches to the others
for review.

They could also push their changes by creating a full clone on
git.debian.org/home/.../
and integrating their patches created using the "subtree clone" there.

Cheers,
Balint

Re: Let's stop using CVS for debian.org website

[Bálint Réczey]

Hi,

2016-11-24 12:20 GMT+01:00 Jonas Smedegaard :
> Quoting Holger Levsen (2016-11-24 10:43:40)
>> As some people fear the size of the git repo, I've done a test:
>>
>> cloning took 5-6min (granted over a fast network connection) and requires
>> 628mb of diskspace in the end.
>>
>> however, cloning using --depth 1 did not work :(
>>
>> $ git clone --depth 1 https://anonscm.debian.org/cgit/webwml/webwml2git.git
>> Cloning into 'webwml2git'...
>> fatal: The remote end hung up unexpectedly
>> fatal: protocol error: bad pack header
>>
>> however if I clone locally (well using file://…) with --depth 1 I can
>> see that it needs 454mb diskspace.
>>
>> Not too bad IMO.
>
> Interesting data points.
>
> Can you get these related data points too? - relevant for those with
> limited internet bandwidth (as is the case for some translators):
>
>   * amount of data transfered over the wire for initial full git clone
>   * amount of data transfered over the wire for shallow git clone
>   * amount of data transfered over the wire for CVS clone
>   * disk space used for CVS clone

I have just learned a new trick which would help people with limited bandwidth.

It is not a subtree clone, but the result is practically the same and
the downloaded data is minimal:
$ git archive --remote=ssh://git.debian.org/git/collab-maint/ffmpeg.git
master debian/ | tar xvf -

It does not work with GitHub, but does perfectly with git.debian.org.

Cheers,
Balint

Credit: http://stackoverflow.com/a/25771130

Re: [RFC] Enabling bindnow by default in dpkg-buildflags?

[Bálint Réczey]

Hi Guillem,

2016-11-23 2:30 GMT+01:00 Guillem Jover :
> Hi!
>
> This was discussed relatively recently, but it was not entirely clear
> to me what was the conclusion, if there was any(?), about enabling
> bindnow by default.
>
> And although this got enabled by default in gcc-6 6.2.0-7 when PIE
> also got enabled, it seems it got disabled in 6.2.0-10 when I pointed
> out that enabling bindnow in gcc w/o enabling relro too didn't seem to
> make much sense, but then I didn't notice any rationale for the
> reversion, instead of say enabling relro too.

GCC enabled bindnow only for architectures which also enabled
PIE by default, but unlike PIE there were no architecture-specific
objections against enabling bindnow.

I think talking to Matthias (@Matthias: talking to Guillem) and
reaching a consensus would be badly needed for the project.

>
>
> My mine concern is and has always been that bindnow changes the
> run-time behavior (instead of the build-time one) and could break
> things such as dlopen() on shared libraries or plugins and similar.
> And detecting problems becomes harder, and reverting this change
> iff we notice that it breaks too much might imply rebuilding an
> unspecified number of packages. So in a way it feels kind of like
> a transition?
>
> OTOH Ubuntu seems to have been enabling not only PIE and bindnow by
> default in gcc for a long time, but also relro, stack-protector and
> fortify. Which would seem to imply this might not break that much?
> (I'm not sure why we are not enabling all those in gcc in Debian
> too, but that's probably a different conversation to have if at all.)

Lucas already performed the archive-wide rebuild with bindnow
enabled by dpkg and we have not observed breakages specific to
bindnow. IMO this is mostly due to packages already disabling
bindnow through dpkg-buildflags.

Considering that we are already in the transition freeze I suggest
going with enabling bindnow for all architectures in dpkg and
for Stretch+1 the responsibility of setting some hardening flags
could be transferred to gcc.
IMO this is not a transition because the change does not affect
package interdependencies.

Cheers,
Balint

>
>
> So at this point, I guess I still have concerns, but only very mild
> ones, and would not mind one way or another, but would like input
> from at least the release team, because I don't feel like possibly
> deciding on this on my own, even more at this stage of the release.
>
> Thanks,
> Guillem

Re: Static linking and fPIC (Was: Re: "PIE by default" transition is underway -- wiki needs updating)

[Bálint Réczey]

Hi Ian,

2016-10-31 14:19 GMT+01:00 Ian Campbell <i...@debian.org>:
> On Mon, 2016-10-31 at 12:17 +0100, Bálint Réczey wrote:
>> 2016-10-31 10:38 GMT+01:00 Ian Campbell <i...@debian.org>:
>> > If possible I'd also prefer a solution which fixed qcontrol-static
>> > without opting out for the normal dynamic/non-udeb binary.
>>
>> I ran the build tests on amd64, this is why I have not caught this error.
>> A rebuild of lua5.1 should fix the problem.
>>
>> Dpkg changes are on their way, too in the next days. I would ask
>> for a binNMU after dpkg is updated.
>
> Thanks, to check I understand: I should wait for #835146 to be fixed in
> sid (which is expected to happen via a dpkg upload in the next days)
> and then ask for a binNMU of lua5.1 then qcontrol (or maybe I have
> reason to upload a newer qcontrol anyway, we'll see)?

Yes, this should fix qcontrol and maybe you don't even have to ask for
rebuilds.  I think there is already an archive-wide rebuild planned to
make reproducibility-related changes in dpkg take effect thus I suggest
waiting a few days to see if you need to ask for binNMUs.

Cheers,
Balint

Re: Static linking and fPIC (Was: Re: "PIE by default" transition is underway -- wiki needs updating)

[Bálint Réczey]

2016-10-31 12:52 GMT+01:00 Henrique de Moraes Holschuh :
> On Mon, 31 Oct 2016, Ian Campbell wrote:
>> On Mon, 2016-10-31 at 10:27 +0100, Jérémy Lal wrote:
>> > export DEB_BUILD_MAINT_OPTIONS = hardening=+all,-pie
>> > ?
>>
>> Thanks, but that doesn't appear to help, I think the issue is to do
>> with the changed default in gcc rather than the hardening settings
>
> Which is actually a bug: hardening=-pie (now) needs to actually inject
> flags to disable PIE, instead.

It is indeed a bug, but not an easily solvable one:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=835149

Cheers,
Balint

Re: Static linking and fPIC (Was: Re: "PIE by default" transition is underway -- wiki needs updating)

[Bálint Réczey]

Hi Ian,

2016-10-31 10:38 GMT+01:00 Ian Campbell :
> On Mon, 2016-10-31 at 10:27 +0100, Jérémy Lal wrote:
>> export DEB_BUILD_MAINT_OPTIONS = hardening=+all,-pie
>> ?
>
> Thanks, but that doesn't appear to help, I think the issue is to do
> with the changed default in gcc rather than the hardening settings
> injected into the build by dpkg-buildpackage/dpkg-buildflags (or
> whatever it is which does it).

Yes, this is the case.

>
> If possible I'd also prefer a solution which fixed qcontrol-static
> without opting out for the normal dynamic/non-udeb binary.

I ran the build tests on amd64, this is why I have not caught this error.
A rebuild of lua5.1 should fix the problem.

Dpkg changes are on their way, too in the next days. I would ask
for a binNMU after dpkg is updated.

Cheers,
Balint

Re: Doxygen has 3 RC bugs preventing packages to build - is droping documentation a sensible option?

[Bálint Réczey]

Hi Andreas,

2016-10-28 13:41 GMT+02:00 Andreas Tille <andr...@an3as.eu>:
> On Fri, Oct 28, 2016 at 01:27:27PM +0200, Bálint Réczey wrote:
>> > What do you think about the "droping documentation since it breaks the
>> > package build" idea?
>>
>> In a similar situation I worked around the issue and preprocessed the
>> broken latex input to fix the unescaped characters.
>
> Could you please name the "similar situation" ;-) to let me sneak into
> your code?

I think it was libcaca and #728069 but in the final solution I did not parse
the file just called pdflatex several times.

Cheers,
Balint

Re: Doxygen has 3 RC bugs preventing packages to build - is droping documentation a sensible option?

[Bálint Réczey]

Hi,

2016-10-28 13:09 GMT+02:00 Andreas Tille :
> Hi,
>
> I really want to update cimg since a long time, missing several upstream
> releases but I cimg does not build due to #836168.  In the bug report it
> was also suggested to use sphinx as doxygen replacement but I'm not sure
> how sensible this might be since upstream is using doxygen.
>
> Since there is no real progress with doxygen (3 RC bugs no relevant
> trafic) I seriously consider droping the doxygen documentation for cimg
> at all and recommend users to live with the online documentation.  I do
> not consider this a good solution but if cimg will not be uploaded soon
> this will also affect opencv transition.
>
> What do you think about the "droping documentation since it breaks the
> package build" idea?

In a similar situation I worked around the issue and preprocessed the
broken latex input to fix the unescaped characters.

Cheers,
Balint

Re: "PIE by default" transition is underway -- wiki needs updating

[Bálint Réczey]

Hi,

2016-10-27 4:03 GMT+02:00 Steve M. Robbins :
> On Wed, Oct 26, 2016 at 05:26:24AM +0200, Guillem Jover wrote:
>
>> My point was that, yes we have changed to generating relocatable code
>> but that is still targetted for executables only, which preserves the
>> current behavior, [...]
>
> But something must have changed with how a static lib is now compiled,
> because (a) I see bug reports saying "foo broke because static libbar
> is not -fPIC" and (b) the recommended fix is to rebuild libbar with
> the new toolchain -- with no source changes.
>
> So what's going on with static libs?

As a preparation for the transition I suggested using PIC for static
libraries for some packages and also suggested changing the Policy
to be more liberal about that.  (#837478)
I followed the current Policy and opened discussion on debian-devel
before enabling PIC in the affected packages:
https://lists.debian.org/debian-devel/2016/09/msg00277.html

I have updated some of the affected packages according the current
Policy.

A few weeks later Adrian shared his concerns with this approach
and preferred simple binNMU-s for affected static librarie because
it also fixes the build issues. The reasoning can be read in the same
bug.

Some binNMU-s already took place.
Adrian also filed bugs for reverting the changes enabling PIC for
static libraries.

This is where we are now. I guess the rest of the binNMUs will take
place soonish. The Policy may or may not be changed depending on
new inputs in #837478.

Cheers,
Balint

Re: "PIE by default" transition is underway -- wiki needs updating

[Bálint Réczey]

Hi Steve,

2016-10-25 5:31 GMT+02:00 Steve M. Robbins :
> Hi,
>
> I haven't been paying close attention to the "PIE by default" [1] discussions,
> so I may have missed the memo, but: it seems the transition is underway?

GCC have been changed to enable PIE by default but dpkg has not been
changed yet.

>
> I've seen two bugs already claiming "static library foo must be compiled with
> -fPIC" -- because some reverse dependency now fails to build.  But I think
> this advice is misplaced.  The Ubuntu page [2] says that all you need to do is
> rebuild the library foo with the PIE-enabled compiler, then rebuild the
> depending code:
>
> Relocation Linking Failure
>
> A dynamically linked program that pulls in a static library that was 
> not
> built with -fPIC. These give an error like:
>
> relocation R_X86_64_32 against '[SYMBOL]' can not be used when 
> making a
> shared object; recompile with -fPIC
>
> To address these types of issues, the package providing the static 
> object
> needs to be rebuilt (usually just a no-change rebuild against the 
> pie-by-
> default compiler) before rebuilding the failed package.
>
>
> So it seems to me that this should be emphasized on the wiki [1].  Secondly,

I filed the original bugs with the following template, which contains
"Please", not
"must": "Please build .a with -fPIC"
It seems it was a mistake not emphasizing that a rebuild can also solve most of
the FTBFS bugs, and I have now updated the wiki, too.


> it seems that the proposal to change policy to encourage -fPIC on static
> libraries [3] is misplaced and should be withdrawn.Are both these
> statements accurate?

It have updated the wiki making it clear, that the Policy may not be changed.

Thanks,
Balint

>
> Thanks,
> -Steve
>
> [1] https://wiki.debian.org/Hardening/PIEByDefaultTransition
> [2] https://wiki.ubuntu.com/SecurityTeam/PIE
> [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837478

Re: Bug#835533: dasher: Please package Dasher 5.0 beta

[Bálint Réczey]

Hi,

2016-10-06 8:46 GMT+02:00 Scott Kitterman :
>
>
> On October 6, 2016 2:04:36 AM EDT, Samuel Thibault  
> wrote:
>>Paul Wise, on Thu 06 Oct 2016 11:40:12 +0800, wrote:
>>> On Thu, Oct 6, 2016 at 12:53 AM, Samuel Thibault wrote:
>>> > So if some of these packages is falling down, the
>>debian-accessibility
>>> > team *has* to be notified so we can find a solution. Maybe we
>>should
>>> > put in the ftp-master process that an RM request for any kind of
>>> > accessibility-related package shouldn't be processed without an ACK
>>from
>>> > the debian-accessibility team?
>>>
>>> These kind of issues aren't specific to removal of accessibility
>>> packages;
>>
>>The kind of issue isn't specific indeed. But the consequence is
>>specific: the result is that some people can not use Debian any more at
>>all. That's very different from just missing a program you really want
>>to have.
>>
>>Scott Kitterman, on Thu 06 Oct 2016 00:08:19 -0400, wrote:
>>> It's extremely rare that a removal is problematic.  It does happen
>>and in
>>> cases where it does, the FTP team is generally happy to expedite a
>>package
>>> back through New.
>>>
>>> Speaking only for myself, I think the level of work implied in your
>>request
>>> translates into removals don't happen.  If you think this work should
>>be done,
>>> I encourage you to comment on the removal bugs requesting that the
>>removal be
>>> held in abeyance while you do it (also adding a moreinfo tag is
>>helpful).
>>
>>I'm not sure to understand what you meant exactly here.
>>debian-accessibility wasn't aware of the RM request before it was
>>processed. Realizing that and having to go through NEW again is not
>>technically hard, sure, but it takes a lot of energy to go pass the
>>frustration that it happened at all.
>
> Agreed it's frustrating, but I don't think it's the FTP Team's job to second 
> guess a maintainer request for removal of a buggy package.  I doubt most 
> people appreciate the volume of rm bugs.  FTP Team spending significant time 
> figuring out if maybe someone else might care just doesn't scale.
>
> As frustrating as occasional removal/reintroduction cycles are, they are rare 
> enough that despite the frustration when they occur it's really not worth the 
> effort it would take to avoid them completely.

I agree that we should not ask the FTP Team to take extra
steps before performing removals. They already take care of many things and
nowadays nowadays they act on uploads to NEW amazingly fast!

Dear FTP Team, thank you, accepting packages with so little delay is a
huge help!

If there is something that we can do related to removals then it would be
waiting with the removals one or two weeks after the removal request is filed.
This time would most probably be enough for interested parties to
fix the package or at least signal their intentions.

Regarding dasher I did the last upload around the last freeze to keep
it in stable
and my plan was packaging new upstream for Stretch, but I was busy
with other packages which require a transition thus should be ready
this month.

I'm sorry for not stating that in dasher's bugs, but I would have
shared my plans
if I knew about the removal.

Thibaut Paumard already filed an ITP and thank you for that.

Requesting the removal was a mistake IMO, but it can be fixed. We will
ship dasher in Stretch and we still care about people who need it for
using their computers.

Cheers,
Balint

Re: Exception for shipping shared libraries compiled with -fPIC for multiple packages

[Bálint Réczey]

Hi,

2016-09-15 20:19 GMT+02:00 Raoul Borenius :
> Hello all,
>
> On Wed, Sep 14, 2016 at 01:02:02AM +0200, Balint Reczey wrote:
>> Dear People of Debian-Devel,
>>
>> Current Policy (3.9.8.0) mandates discussion on debian-devel@d.o
>> before changing packages to ship static libraries compiled with -fPIC:
>>
>> ---
>> 10.2 Libraries
>> ... (paragraph about shared libs)
>
>> I am hereby asking for exceptions for the following packages:
>>
>>   Bug  Package Title
>> #586572 libdpkg-dev   libdpkg-dev: Please provide a libdpkg 
>> shared library
>> #712228 src:ghc   Hardening flag -pie breaks compilation 
>> with GHC
>> #804254 publib-devpublib-dev: please build libpub.a with 
>> -fPIC
>> #837350 src:binutils  binutils: Please build libbfd.a with 
>> -fPIC
>> #837359 src:ocaml ocaml: Please build libasmrun.a and 
>> libcamlrun.a with -fPIC
>> #837363 src:cpputest  cpputest: Please build libCppUTest.a 
>> with -fPIC
>> #837417 src:ctn   ctn: Please build libctn.a with -fPIC
>> #837423 src:jack-audio-connection-kit jack-audio-connection-kit: Please 
>> build libjack.a with -fPIC
>> #837424 src:portaudio19   portaudio19: Please build 
>> libportaudio.a with -fPIC
>> #837434 src:binpacbinpac: Please build libbinpac.a with 
>> -fPIC
>> #837445 src:check check: Please build libcheck.a with 
>> -fPIC
>> #837452 src:simgear   simgear: Please build libSimGearCore.a 
>> and libSimGearScene.a with -fPIC
>> #837489 src:antlr antlr: Please build libantlr.a with 
>> -fPIC
>> #837490 src:libpapyrus3-dev   libpapyrus3-dev: Please build 
>> libPapyrus3.a with -fPIC
>> #837491 src:libgadap-dev  libgadap-dev: Please build libgadap.a 
>> with -fPIC
>
> I would like to add
>
> #837400 src:i2utillibi2util-dev: Please build libI2util.a 
> with -fPIC
>
> to the list.


Even positive feedback would be nice regarding the exceptions. :-)

If no one objects I will start updating the affected packages tomorrow which I'm
team-maintaining and which are maintained by QA.
For the rest I will update the bugs that the exception can be
considered granted.

Cheers,
Balint

Re: PIE and static libraries

[Bálint Réczey]

Hi Markus,

2016-09-12 8:51 GMT+02:00 Markus Wanner <mar...@bluegap.ch>:
> On 09/12/2016 01:47 AM, Bálint Réczey wrote:
>> I have opened a bug to encourage PIC for static libraries in Policy, too.:
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837478
>
> Thanks, cool.
>
> Is there any specific reason for not mentioning -fPIE in that request?
> That seems like a good middle-ground for static libraries.
>
> Reading up on the subject so far, I got the impression that most static
> libraries should be built with PIE, but not necessarily PIC (to allow
> building PIE(xecutable)s, but discourage creating shared libraries from
> those static ones.)

I don't see why should not we encourage using static libs in shared libs
and recommending PIC would also simplify the currently mandated build process:

10.2 Libraries
... (paragraph about shared libs requiring PIC)

As to the static libraries, the common case is not to have relocatable
code, since there is no benefit, unless in specific cases; therefore the
static version must not be compiled with the -fPIC flag. Any exception
to this rule should be discussed on the mailing list
debian-devel@lists.debian.org, and the reasons for compiling with the
-fPIC flag must be recorded in the file README.Debian. [86]

In other words, if both a shared and a static library is being built,
each source unit (*.c, for example, for C files) will need to be
compiled twice, for the normal case.
...

>
> To be honest, I didn't really check any use-case other than
> libsimgear-dev, which I'm concerned about.

There is a (still growing:-)) list in here which includes other PIE
releated issues:
https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=pie-bindnow-20160906=balint%40balintreczey.hu

Cheers,
Balint

Re: PIE and static libraries

[Bálint Réczey]

Hi All,

2016-05-22 11:26 GMT+02:00 Christian Seiler :
> On 05/22/2016 10:50 AM, Andrey Rahmatullin wrote:
>> On Sun, May 22, 2016 at 10:41:56AM +0200, Christian Seiler wrote:
...
>
>>> B. From a performance perspective, using non-PIC/PIE code is
>>>faster, though not necessarily by much anymore.
>> It was worth mentioning only for i386 anyway.
>
> Well, there's not only amd64 and i386 - and some other platforms
> also show some differences here. But as I said: I would recommend
> to use PIE/PIC anyway.

I have opened a bug to encourage PIC for static libraries in Policy, too.:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837478

Cheers,
Balint

FTBFS with PIE & bindnow (was: Re: Porter roll call for Debian Stretch)

[Bálint Réczey]

Hi,

First of all thanks to Lucas Nussbaum who ran the first test build!

2016-08-31 19:21 GMT+02:00 Steve Langasek :
> On Wed, Aug 31, 2016 at 11:26:55AM +0100, Dimitri John Ledkov wrote:
>> Hello,
>> > Results are available at
>> > https://people.debian.org/~lucas/logs/2016/08/30/pie-bindnow-20160830/
>
>> > I did a full rebuild with bindnow and PIE enabled, then rebuilt all
>> > failed packages with a pristine unstable chroot.
>
>> > You can take a look at
>> > https://people.debian.org/~lucas/logs/2016/08/30/pie-bindnow-20160830/diff.txt
>> > and grep for "OK Failed" (failed with PIE+bindnow, built fine in
>> > unstable). (There are 1188 packages failing to build)
>
>> > Logs for both builds are available in the respective subdirectories.
>
>> Are you sure these are correct? The numbers for PIE+bindnow are a lot
>> higher than what we see in Ubuntu, for same unmodified packages.
>
>> E.g. looking at http://qa.ubuntuwire.org/ftbfs/
>
>> amd64/ppc64el/s390x have PIE+bindnow enabled, and
>> i386/armhf/arm64/powerpc do not. here is nothing in the thousands
>> range. There might be a dozen packages with PIE+bindnow fixes in
>> ubuntu, that's not in debian, but that amount cannot be more than a
>> dozen or two.

Is there a list available or an easy way of collecting them?

>
> Note that enabling PIE by default is going to cause build failures for a
> number of packages which link against static libraries, if those static
> libraries have not been rebuilt yet with PIE/PIC.  Ubuntu has worked through
> this transition, so a direct comparison would require a rebootstrap test in
> Debian instead of just a rebuild test (i.e.: test rebuild packages in
> dependency order, and build later packages against the output of the earlier
> rebuilds).

True. Full rebootstrapping of the archive is not available
automatically and this
was really useful as a first test.

I have added more dpkg patches [1] to make -pie hardening flag a noop since GCC
upstream is not interested in making -no-pie easily usable [2].

I tested the packages failing to build with the previous patches and
many of them
could be built.
The logs of the remaining failures can be found here:
https://people.debian.org/~rbalint/build-logs/pie-bindnow-20160906/

If we ignore the packages having "haskell" in their name the failures are down
to 295 packages.

I'm starting ot file bugs for the FTBFS-s.

Patched dpkg and gcc is still available for those who would like to reproduce
the issues.

Cheers,
Balint

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=835149
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77464
[3] https://people.debian.org/~rbalint/ppa/pie-bindnow/

Re: Porter roll call for Debian Stretch

[Bálint Réczey]

Hi,

2016-08-31 12:26 GMT+02:00 Dimitri John Ledkov <x...@debian.org>:
> Hello,
>
> On 30 August 2016 at 23:07, Lucas Nussbaum <lu...@debian.org> wrote:
>> On 22/08/16 at 19:12 +0200, Bálint Réczey wrote:
>>> Hi Guillem,
>>>
>>> 2016-08-21 14:02 GMT+02:00 Guillem Jover <guil...@debian.org>:
>>> > Hi!
>>> >
>>> > On Sun, 2016-08-21 at 10:24:42 +0200, Bálint Réczey wrote:
>>> >> I'm testing a set of patches [2] for gcc and dpkg which enable bindnow 
>>> >> for all
>>> >> arches and PIE for amd64, ppc64el and s390x in sync with Ubuntu.
>>> >>
>>> >> My assumption was that this set of architectures need the least amount of
>>> >> additional work since they are tested already in Ubuntu, but I would be 
>>> >> happy
>>> >> if more ports would opt in for PIE.
>>> >>
>>> >> I plan filing wishlist bugs against dpkg and gcc with the patches
>>> >> after I rebuilt a
>>> >> few packages with the defaults.
>>> >
>>> > TBH I think PIE should in fact be safer to enable globally than
>>> > bindnow, because the latter changes the run-time behavior and things
>>> > might break (perhaps even silently) when failing to load plugins
>>> > or similar.
>>>
>>> Yes, in that sense enabling PIE is safer indeed. Regarding bindnow
>>> I don't expect too many surprises either, since other distributions
>>> already tested enabling bindnow and probably they found
>>> most issues.
>>>
>>> >
>>> > From dpkg PoV enabling both, would at least require a full-archive
>>> > rebuild, for bindnow ideally also a full autopkgtest run (as the
>>> > updated dpkg FAQ states now, after Lucas Nussbaum approached me some
>>> > weeks ago mentioning he was willing to do such archive-wide rebuild).
>>>
>>> The patches at [2] seem to work well and since you expressed that you would
>>> prefer changing both toolchain and dpkg, too, I would like to suggest 
>>> running
>>> the rebuild with those patches.
>>>
>>> I think Matthias would be OK with the patch since it is very small and 
>>> brings
>>> Debian's gcc closer to Ubuntu's.
>>>
>>> Lucas, could you please run the rebuild with the three patches?
>>
>> Hi,
>>
>> Results are available at
>> https://people.debian.org/~lucas/logs/2016/08/30/pie-bindnow-20160830/
>>
>> I did a full rebuild with bindnow and PIE enabled, then rebuilt all
>> failed packages with a pristine unstable chroot.
>>
>> You can take a look at
>> https://people.debian.org/~lucas/logs/2016/08/30/pie-bindnow-20160830/diff.txt
>> and grep for "OK Failed" (failed with PIE+bindnow, built fine in
>> unstable). (There are 1188 packages failing to build)
>>
>> Logs for both builds are available in the respective subdirectories.
>>
>> Lucas
>>
>
> Are you sure these are correct? The numbers for PIE+bindnow are a lot
> higher than what we see in Ubuntu, for same unmodified packages.
>
> E.g. looking at http://qa.ubuntuwire.org/ftbfs/
>
> amd64/ppc64el/s390x have PIE+bindnow enabled, and
> i386/armhf/arm64/powerpc do not. here is nothing in the thousands
> range. There might be a dozen packages with PIE+bindnow fixes in
> ubuntu, that's not in debian, but that amount cannot be more than a
> dozen or two.
>
> Looking at e.g. ace buildlog the PIE+bindnow has this:
> -fno-PIE -no-pie -Wl,-z,relro -Wl,-z,now
>
> Which is bindnow without pie, instead of with pie.

Ubuntu sets bindnow in GCC in Ubuntu while it is set by dpkg in Debian.

Ace requests those flags in d/rules:
...
export DEB_BUILD_MAINT_OPTIONS =
hardening=+format,+fortify,+stackprotector,+relro,+bindnow,-pie
...

I have just started looking at the logs and I think I have a patch to GCC which
will fix many of the FTBFS-es.
I'm also looking at the GCC diff in Ubuntu.

Cheers,
Balint

>
> And same ace build fine in Ubuntu, with PIE+bindnow on the relevant
> arches. https://launchpad.net/ubuntu/+source/ace/6.3.3+dfsg-1.1
>
> --
> Regards,
>
> Dimitri.

Re: PIE + bindnow for Stretch?(Re: Time to reevaluate the cost of -fPIC?)

[Bálint Réczey]

Hi All,

2016-05-28 23:16 GMT+02:00 Bálint Réczey <bal...@balintreczey.hu>:
> Hi,
>
> 2016-05-18 2:21 GMT+02:00 Guillem Jover <guil...@debian.org>:
>> On Tue, 2016-05-17 at 12:08:09 +0200, Matthias Klose wrote:
>>> I'm not a fan myself for turning on hardening flags in the compiler itself,
>>> but if you do that, then dpkg issues like https://bugs.debian.org/823869
>>> need to be addressed (whether all obscure build systems picking these up, or
>>> not).
>>
>> That bug report is not relevant in its current form, as explained
>> there.
>>
>> If the default changes in the Debian default compiler, then I'll just
>> make the +pie option a no-op and change -pie to set -fno-PIE, so that
>> the options are only added when they are expected.
>>
>> The difference with that request is that it would currently add
>> -fno-PIE for most packages that do not change the default flags,
>> which might break their build-systems.
>
> Thank you Guilllem.
>
> Matthias, are you OK with the resolution of #823869 and would you be
> OK with using --enable-default-pie for GCC if dpkg adopts the solution
> described above?

For the record I have opened #835146, #835148 and #835149 against dpkg
and gcc-6 with a set of proposed patches [2] which seem to work well.

[2] https://people.debian.org/~rbalint/ppa/pie-bindnow/

Re: Porter roll call for Debian Stretch

[Bálint Réczey]

Hi Guillem,

2016-08-21 14:02 GMT+02:00 Guillem Jover <guil...@debian.org>:
> Hi!
>
> On Sun, 2016-08-21 at 10:24:42 +0200, Bálint Réczey wrote:
>> I'm testing a set of patches [2] for gcc and dpkg which enable bindnow for 
>> all
>> arches and PIE for amd64, ppc64el and s390x in sync with Ubuntu.
>>
>> My assumption was that this set of architectures need the least amount of
>> additional work since they are tested already in Ubuntu, but I would be happy
>> if more ports would opt in for PIE.
>>
>> I plan filing wishlist bugs against dpkg and gcc with the patches
>> after I rebuilt a
>> few packages with the defaults.
>
> TBH I think PIE should in fact be safer to enable globally than
> bindnow, because the latter changes the run-time behavior and things
> might break (perhaps even silently) when failing to load plugins
> or similar.

Yes, in that sense enabling PIE is safer indeed. Regarding bindnow
I don't expect too many surprises either, since other distributions
already tested enabling bindnow and probably they found
most issues.

>
> From dpkg PoV enabling both, would at least require a full-archive
> rebuild, for bindnow ideally also a full autopkgtest run (as the
> updated dpkg FAQ states now, after Lucas Nussbaum approached me some
> weeks ago mentioning he was willing to do such archive-wide rebuild).

The patches at [2] seem to work well and since you expressed that you would
prefer changing both toolchain and dpkg, too, I would like to suggest running
the rebuild with those patches.

I think Matthias would be OK with the patch since it is very small and brings
Debian's gcc closer to Ubuntu's.

Lucas, could you please run the rebuild with the three patches?

I'll attach the patches to the bug reports.

Cheers,
Balint

[2] https://people.debian.org/~rbalint/ppa/pie-bindnow/

Re: Porter roll call for Debian Stretch

[Bálint Réczey]

Hi,

2016-08-21 8:22 GMT+02:00 Niels Thykier :
> Kurt Roeckx:
>> On Wed, Aug 17, 2016 at 10:05:06PM +0200, ni...@thykier.net wrote:
>>>  * If we were to enable -fPIE/-pie by default in GCC-6, should that change
>>>also apply to this port? [0]
>>
>> If -fPIE is the default will -fPIC override it?
>>
>> It will also default to tell the linker to use -pie, but then
>> don't do it when you want to create a shared library?
>>
>
> I believe so.  At least, Ubuntu made PIE default in their compiler
> without having to change all SO packages to still build.
>
> Admittedly, it could also be that GCC uses some built "compiler spec"
> files for this case (a la an implicit "-specs=$FILE"), which are similar
> to those Redhat uses for this purposes (see [1] for an example of such
> files).
>
> Regardless, it seems to "just work(TM)" if you pass the proper flags
> when compiling your SOs.
>
>>>From what I understand, depending on what the .o file is going to
>> be used for you want different things:
>> - shared library: -fPIC
>> - executable: -fPIC or -fPIE both work, but prefer -fPIE
>> - static library: Same as executables
>>
>> For static libraries we now have a policy to not use -fPIC,
>> should that then get replaced by using -fPIE?
>>
>>
>>
>> Kurt
>>
>
> Honestly, I had not thought about that.  From the looks of it, de facto
> we will end up with -fPIE being the default for static libraries as well.
>   I would be supporting that change on the assumption that it requires
> less work from individual maintainers (and presumably has no notable
> downsides in the final result).

I'm testing a set of patches [2] for gcc and dpkg which enable bindnow for all
arches and PIE for amd64, ppc64el and s390x in sync with Ubuntu.

My assumption was that this set of architectures need the least amount of
additional work since they are tested already in Ubuntu, but I would be happy
if more ports would opt in for PIE.

I plan filing wishlist bugs against dpkg and gcc with the patches
after I rebuilt a
few packages with the defaults.

Cheers,
Balint

[2] https://people.debian.org/~rbalint/ppa/pie-bindnow/


>
> Thanks,
> ~Niels
>
> [1] Example spec files for this case seems to be something like:
>
> pie-compile.specs
> """
> *cc1_options:
> + %{!r:%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fPIE}}
> """
>
> pie-link.specs:
> """
> *self_spec:
> + %{!shared:%{!r:-pie}}
> """
>
> NB: I manually carved them out of a diff without testing them.
>

Re: PIE + bindnow for Stretch?(Re: Time to reevaluate the cost of -fPIC?)

[Bálint Réczey]

Hi,

2016-05-18 2:21 GMT+02:00 Guillem Jover :
> On Tue, 2016-05-17 at 12:08:09 +0200, Matthias Klose wrote:
>> I'm not a fan myself for turning on hardening flags in the compiler itself,
>> but if you do that, then dpkg issues like https://bugs.debian.org/823869
>> need to be addressed (whether all obscure build systems picking these up, or
>> not).
>
> That bug report is not relevant in its current form, as explained
> there.
>
> If the default changes in the Debian default compiler, then I'll just
> make the +pie option a no-op and change -pie to set -fno-PIE, so that
> the options are only added when they are expected.
>
> The difference with that request is that it would currently add
> -fno-PIE for most packages that do not change the default flags,
> which might break their build-systems.

Thank you Guilllem.

Matthias, are you OK with the resolution of #823869 and would you be
OK with using --enable-default-pie for GCC if dpkg adopts the solution
described above?

Cheers,
Balint

Re: PIE + bindnow for Stretch?(Re: Time to reevaluate the cost of -fPIC?)

[Bálint Réczey]

Hi,

2016-05-16 13:09 GMT+02:00 Christoph Egger :
> Hi!
>
> Iustin Pop  writes:
>> - that bug seems to have been opened in the context of custom patches to
>>   GCC, back in 2009-2012
>> - the CTTE seems to have made an informal decision (see last update
>>   #272) on that topic
>
> And most importantly
>
>   - the tech-ctte primarily refused to override the maintainer. And the
> maintainer's primary objection was the patch not being upstream.

Thanks for pointing that out. I have re-read the whole bug log [1] and
I agree that since CTTE made and informal decision we don't have to
reopen the discussion there. (I assume most of the CTTE members
are reading this list, too, please speak up if I'm mistaken here.)

In the best scenario Matthias and Guillem can agree on a solution
and a test build can be run to see which packages need patching.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=552688

Re: PIE + bindnow for Stretch?(Re: Time to reevaluate the cost of -fPIC?)

[Bálint Réczey]

Hi Niels,

2016-05-15 20:49 GMT+02:00 Niels Thykier <ni...@thykier.net>:
> Bálint Réczey:
>> Hi,
>>
>> [...]
>>
>
> Hi,
>
>> I think making PIE and bindnow default in dpkg (at least for amd64) would be
>> perfect release goals for Stretch.
>>
>
> I support the end goal, but I suspect we should enable PIE by default
> via GCC-6's new configure switch[1].  Assuming it does what I hope, then
> it will work better than enabling PIE via dpkg-buildflags.
>
>  * The major issue with PIE by default is that it is not compatible
>with -fPIC (and presumably also -static), which causes FTBFS or
>broken ELF binaries.
>
>  * Assuming the GCC option does what I hope, then it would automatically
>disable PIE for irrelevant outputs.
>
> My assumption seems to be aligned with the approach taking by Ubuntu.

I agree that it would be the easier way and I also tried building packages with
patched GCC 5 setting PIE as default with success, but we have a CTTE
decision which says that we should set hardening flags through dpkg:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=552688

>
>> This would make Debian on par with Fedora and Ubuntu in that regard.
>>
>
> FTR, Fedora seems to have some special logic for adding PIE only to
> executables.
>
>> We briefly discussed that with Guillem in a related bug report:
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812783#42
>>
>> I think the next step could be an archive rebuild with the changed defaults
>> if we would like to pursue this:
>> https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Can_we_add_support_for_new_default_build_flags_to_dpkg-buildflags.3F
>>
>> I planned starting a discussion on debian-devel about PIE + bindnow,
>> too, after checking
>> all the packages which contain statically compiled binaries because
>> they may need patching
>> to disable PIE flags based on Lunar's post:
>> https://people.debian.org/~lunar/blog/posts/aslr_now/
>>
>> Cheers,
>> Balint
>>
>>>[...]
>
> In summary:
>
>  * I would welcome bindnow by default via dpkg-buildflags.
>
>  * I would also love to have PIE as default for Stretch although I fear
>dpkg-buildflags is the wrong approach for that particular flag.

I would be happy with either of the approaches.

Cheers,
Balint

>
> Thanks,
> ~Niels
>
> [1] https://gcc.gnu.org/gcc-6/changes.html
>
> """The --enable-default-pie configure option enables generation of PIE
> by default."""

PIE + bindnow for Stretch?(Re: Time to reevaluate the cost of -fPIC?)

[Bálint Réczey]

Hi,

2016-05-15 4:11 GMT+02:00 Dimitri John Ledkov :
> On 14 May 2016 at 21:12, Niels Thykier  wrote:
>> Marco d'Itri:
>>> On May 03, Josh Triplett  wrote:
>>>
 While this doesn't make PIC absolutely free, it does eliminate almost
 all of the cost, to the point that it no longer seems worthwhile to
 build without -fPIC.  Apart from that, building *all* code with -fPIC
 (including both programs and libraries) helps with hardening.
>>> I think that this is worth exploring.
>>> Did you check what other (relevant) distributions are doing?
>>>
>>
>> Fedora seems to be doing -fPIE by default for executables[1] - targeting
>> Fedora 23.  Known issues they ran into can be found at [2].
>>   I also found the following PPA [3]. Cannot say if it is official or
>> just a personal interest from the PPA owner.
>>
>
> Ubuntu 16.04 LTS on s390x has -fPIE and bind now
>
> Ubuntu 16.10 on amd64, ppc64el, s390x has -fPIE and bind now

I think making PIE and bindnow default in dpkg (at least for amd64) would be
perfect release goals for Stretch.

This would make Debian on par with Fedora and Ubuntu in that regard.

We briefly discussed that with Guillem in a related bug report:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812783#42

I think the next step could be an archive rebuild with the changed defaults
if we would like to pursue this:
https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Can_we_add_support_for_new_default_build_flags_to_dpkg-buildflags.3F

I planned starting a discussion on debian-devel about PIE + bindnow,
too, after checking
all the packages which contain statically compiled binaries because
they may need patching
to disable PIE flags based on Lunar's post:
https://people.debian.org/~lunar/blog/posts/aslr_now/

Cheers,
Balint

>
> In general features like these for Ubuntu are tracked by Security team at:
>
> https://wiki.ubuntu.com/Security/Features
>
> And bind-now needs fixing on that page.
>
> --
> Regards,
>
> Dimitri.
>

Progress on hardened1-linux-amd64 (was: Re: Proposing amd64-hardened architecture for Debian)

[Bálint Réczey]

Hi All,

2014-04-15 18:15 GMT+02:00 Thomas Goirand :
> On 04/15/2014 06:00 PM, Balint Reczey wrote:
>> Hi,
>>
...
>> My proposal for serving those security-focused users is introducing a
>> new architecture targeting amd64 hardware, but with more security
>> related C/C++ features turned on for every package (currently hardening
>> has to be enabled by the maintainers in some way) through compiler flags
>> as a start.
>>
>> Introducing the new architecture would also let package maintainers
>> enabling additional dependencies and build rules selectively for the new
>> architecture improving the security further. On the users' side the
>> advantage of having a separate security enhanced architecture instead of
>> a Debian derivative is the potential of installing a set of security
>> enhanced packages using multiarch [6]. You could have a fast amd64
>> installation as a base and run Apache or any other sensitive server from
>> the amd64-hardened packages!
>>
>> -
>>
>> What do you think? Would adding a new arch be feasible and a good solution?
>>
>> Cheers,
>> Balint
>
> My take on this: start it if you wish, and see how it takes you. If it
> is successful enough, it will go to http://www.debian-ports.org/. If it
> has even more success, then probably it will go through the standard
> repository and be official part of Debian. Whatever happens, it will be
> interesting to see what kind of performance hit you get, and what kind
> of security enhancement there is.
I made some progress on this wanna-be port in the last months [8]
starting from Helmut's and others' work on rebootsrap [9]. First, the
name is still not final, but has been changed to hardened1-linux-amd64
which fits current port naming better. There are ongoing discussions
regarding the name and I'm working on fulfilling all requirements for
new ports.

The port's objective changed slightly with targeting QA first since I
find too many bugs which prevent using the packages on a stable system
yet. :-)

Right now packages can only be cross-built, thus help on
cross-buildability of packages is highly appreciated especially for
the few missing ones needed for creating a pbuilder/sbuild chroot. You
can try plenty of build-essential packages following the post's [8]
instructions already.

I plan continuing work on this port as my time permits and if there is
significant interest from users. If you are interested and don't want
to share that in public feel free to drop me a mail.

Cheers,
Balint

[8] 
http://balintreczey.hu/blog/progress-report-on-hardened1-linux-amd64-a-potential-debian-port-with-pie-asan-ubsan-and-more/
[9] https://wiki.debian.org/HelmutGrohne/rebootstrap

Re: Clarifications about the alleged transition to FFmpeg

[Bálint Réczey]

Hi Alessio,

2015-06-18 18:00 GMT+02:00 Alessio Treglia ales...@debian.org:
 Hello everybody,

 I am afraid that I have to inform you that Bálint's blog post [1]
 about the current status of libav's provided is untrue as there's
 still a discussion ongoing on the Debian Multimedia Maintainers' team
 mailing list, and a clear outcome is yet to come.
 We'll eventually get in touch with the release team once we've taken a
 final decision on the matter.
Untrue is a nice word, but AFAIK the Multimedia Team which I'm member
of at the moment is really working out the details of the transition.
While the team has not announced a formal decision the majority of the
team supports FFmpeg (which you don't ;-).
It also not clear how the team can make a formal decision since there
is no official leader, just members,not all listed members
participated in the discussion.
From: https://wiki.debian.org/DebianMultimedia :

 Currently there are no strict roles defined. All members can work
 on all packages, although there is some sort of split. A list of
 people actively involved in the packaging effort can be found here


 Last but not least, just a small memo for Bálint: please refrain from
 playing dirty, we have had quite enough of your behaviour.
If those 'we' could find me via private email we could discuss that.
Note that in my very short blog post I invited people to the
discussion which had no new comment for 9 days.

Cheers,
Balint



 Cheers.

 [1] http://balintreczey.hu/blog/debian-is-preparing-the-transition-to-ffmpeg/


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cak0odpwqfnckavus3+be8wsi27euwcf2yz3fpb+917fosvm...@mail.gmail.com

Re: Clarifications about the alleged transition to FFmpeg

[Bálint Réczey]

2015-06-18 18:30 GMT+02:00 Bálint Réczey bal...@balintreczey.hu:
 Hi Alessio,

 2015-06-18 18:00 GMT+02:00 Alessio Treglia ales...@debian.org:
 Hello everybody,

 I am afraid that I have to inform you that Bálint's blog post [1]
 about the current status of libav's provided is untrue as there's
 still a discussion ongoing on the Debian Multimedia Maintainers' team
 mailing list, and a clear outcome is yet to come.
 We'll eventually get in touch with the release team once we've taken a
 final decision on the matter.
 Untrue is a nice word, but AFAIK the Multimedia Team which I'm member
 of at the moment is really working out the details of the transition.
 While the team has not announced a formal decision the majority of the
 team supports FFmpeg (which you don't ;-).
 It also not clear how the team can make a formal decision since there
 is no official leader, just members,not all listed members
 participated in the discussion.
 From: https://wiki.debian.org/DebianMultimedia :

  Currently there are no strict roles defined. All members can work
  on all packages, although there is some sort of split. A list of
  people actively involved in the packaging effort can be found here
Regarding contacting the Release Team we surely have to and will contact them
after the decision is made somehow  _and the transition plan is finalized_ .

Cheers,
Balint


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAK0Odpwx3CgXmnnsHOo7Hmw9q6B8A8dDz78aO-obyRMgKx=r...@mail.gmail.com

Re: Clarifications about the alleged transition to FFmpeg

[Bálint Réczey]

Hi Alessio,

2015-06-18 19:25 GMT+02:00 Alessio Treglia ales...@debian.org:
 On Thu, Jun 18, 2015 at 5:30 PM, Bálint Réczey bal...@balintreczey.hu wrote:
 While the team has not announced a formal decision the majority of the
 team supports FFmpeg (which you don't ;-).

 I've never denied that: [1]
 However you have to give people enough time to ***think***,
 ***review*** things, and ***speak up*** if they wish to.

 It also not clear how the team can make a formal decision since there
 is no official leader, just members,not all listed members
 participated in the discussion.

 No one claims the leadership here, so you can't either I am afraid.
I think a team of this size would need at least a secretary who can set
schedules with deadlines for votes at least when someone delegates
a decision to us. I'm not interested in claiming leadership and if we
ever elect one leader/secretary I won't run and will vote for you in
the first period.

I'm interested in working teams where the rules of making formal
decisions are known and time-limited and I hope when we are
asked to make a decision next time we will have those rules in place.


 From: https://wiki.debian.org/DebianMultimedia :
  Currently there are no strict roles defined. All members can work
  on all packages, although there is some sort of split. A list of
  people actively involved in the packaging effort can be found here

 Correct, nevertheless other members of the team on IRC expressed some
 doubts about the subtle message conveyed by your blog post's title:
 Debian is preparing the transition to FFmpeg! - not to mention other
 parts of the contents (Ending an era of shipping Libav [...] the
 Debian Multimedia Team is working out the last details of switching to
 FFmpeg).
 I do believe that a different wording wouldn't have caused the same reactions.
I'm sorry if some people felt bad due to the wording. I think it is
fairly neutral.
Copying the original short blog entry:
---
 Debian is preparing the transition to FFmpeg!

Ending an era of shipping Libav as default the Debian Multimedia Team
is working out the last details of switching to FFmpeg. If you would
like to read more about the reasons please read the rationale behind
the change on the dedicated wiki page. If you feel so be welcome to
test the new ffmpeg packages or join the discussion starting here.
(Warning, the thread is lng!)
---
I don't know if the IRC logs are available somewhere, but I can update
the post if there are better suggestions for wording.

Cheers,
Balint


 Cheers.

 (I won't reply again, I'm pretty fed up with all this and hope it will
 come to an end soon)

 [1] 
 http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2015-June/044671.html

 --
 Alessio Treglia  | www.alessiotreglia.com
 Debian Developer | ales...@debian.org
 Ubuntu Core Developer|  quadris...@ubuntu.com
 0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAK0Odpw2PbWazC4=E_W=5pjalqej0mkg2jwcvph4kjkzz7d...@mail.gmail.com

Re: Facilitating external repositories

[Bálint Réczey]

Hi Wouter,

2015-06-12 0:59 GMT+02:00 Wouter Verhelst wou...@debian.org:
 On Thu, Jun 11, 2015 at 12:38:29PM +0200, Bálint Réczey wrote:
 Hi Wouter,

 2015-06-07 23:31 GMT+02:00 Wouter Verhelst w...@uter.be:
  On Sun, Jun 07, 2015 at 07:43:30PM +0200, Bálint Réczey wrote:
  I think this situation still allows maintaining the packages in
  Debian, when (if ever) your contract ends and you don't want to
  maintain the packages in your free time you can orphan the packages.
  The next maintainer could adopt the packages then.
 
  Sure, in theory. There are, however, also a few practical reasons why I
  don't want to go down that route (that is, the reasons why I chose to
  allow beid be dropped from Debian in 2010 still apply).
 I have reread the thread twice but I could not find details of the
 practical reasons.

 That would be because they're not mentioned there :-)

 Could you please share them? A link would be enough if I just missed it.

 - I don't want to have to deal with doing a maven build in a Debian
   package. If you see what the packages' debian/rules do, ou'll see that
   we cheat for eid-viewer.
This does not sound like building a binary we could trust.

 - The packages exist mostly to support cards that have a limited
   validity. When they're no longer valid, you return the old one and get
   a new one. Sometimes, it happens that the newer cards have a bug, or
   have a new feature, or some such, which means that the old version of
   the software doesn't really work anymore, and you need a new one.
   Having older versions in the archive for years after they stop working
   turned out to be a support nightmare for upstream.
I think with wheezy-backports the situation improved a lot. The application
could check if *-backports is enabled and warn the user if it is not. You could
keep updated versions in *-backports, thus avoiding the nightmare.

Cheers,
Balint


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAK0Odpw3o+o_Y06v=umnqa1vgabee8oxvhcoqo_7jv395zn...@mail.gmail.com

Re: Facilitating external repositories

[Bálint Réczey]

Hi Wouter,

2015-06-07 23:31 GMT+02:00 Wouter Verhelst w...@uter.be:
 On Sun, Jun 07, 2015 at 07:43:30PM +0200, Bálint Réczey wrote:
 I think this situation still allows maintaining the packages in
 Debian, when (if ever) your contract ends and you don't want to
 maintain the packages in your free time you can orphan the packages.
 The next maintainer could adopt the packages then.

 Sure, in theory. There are, however, also a few practical reasons why I
 don't want to go down that route (that is, the reasons why I chose to
 allow beid be dropped from Debian in 2010 still apply).
I have reread the thread twice but I could not find details of the
practical reasons.
Could you please share them? A link would be enough if I just missed it.

I for example maintain a repository for kodi for for more than a half
year because it sits in the NEW queue and I can't tell how happy I
would be if I could stop building it for amd64, i386 and mipsel (which
is really slow) again and again and I also have to tell armhf users to
wait for official builds because I don't have the HW to build it.

I see eid-mw is built on for i386 and amd64, while I assume it would
build and work perfectly on arm* laptops and computers as well:
https://files.eid.belgium.be/debian/pool/main/e/eid-mw/

Cheers,
Balint


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAK0Odpx8uSd=bjbpqyaytsm3vjmm4uj3tzhx3mftpndu1cw...@mail.gmail.com

Re: Facilitating external repositories

[Bálint Réczey]

Hi Wouter,

2015-06-07 11:08 GMT+02:00 Wouter Verhelst wou...@debian.org:
 On Fri, Jun 05, 2015 at 09:10:56AM -0700, Josh Triplett wrote:
 Wouter Verhelst wrote:
  At $DAYJOB, I'm maintaining a few repositories with ready-to-install
  packages for a number of distributions[1]
 
  Currently, the instructions[2] say to do the following:
  - Download and install an eid-archive package, which contains the GPG
keys and generates a sources.list.d file for the repository;
  - Run apt-get update;
  - Install the eid-mw and/or eid-viewer packages.
 
  This works, but it has a number of downsides:
  - The second step, run apt-get update, is often overlooked; this seems
to be the case especially for users of Ubuntu, where the default
handler for installing packages is the Software Center, a GUI
software management tool that doesn't have any UI element for doing
(the equivalent of) apt-get update
  - There is no trust path from your already-installed distribution to the
archive package (yes, I did sign the gpg keys; no, I don't consider
that enough).
  - It still requires users to manually install packages.

 Given that the packages in question appear to be Free Software (at least
 from a quick check of a couple of them, as well as the repository being
 named main),

 Correct, it's all under GPLv3.

 is there a reason you don't maintain them in Debian
 (including backports or volatile if you need to provide the newest
 packages for older distributions)?

 As others have pointed out, the said software used to be in Debian (I
 was its maintainer). The reasons for pulling it were long, complicated,
 and boring; suffice to say that there were some practical problems.

 (the ftp.d.o bug says no reply from maintainer, which is only half the
 story. At the time I was aware of issues starting to build around beid,
 and trying to figure out how to fix them; I should've probably replied,
 but it occurred to me that pulling was probably a good strategy, at
 least in the short term)

 If that's not an option for some reason, then given that the packages
 are Free Software and of reasonably broad interest, you could at least
 upload a package to Debian containing the archive key, similar to
 pkg-mozilla-archive-keyring; that would establish a trust path.  (Which
 doesn't solve the usability problem, but it does solve the trust
 problem.)

 True, but I don't think it is the best way forward.

 First, it would work for me, as long as I'm still contracting for the
 government[1]. However, due to it being a *government* contract, this is
 an inherently time-limited situation[2]. I want this situation to remain
 manageable after the end of my contract.
I think this situation still allows maintaining the packages in
Debian, when (if ever) your contract ends and you don't want to
maintain the packages in your free time you can orphan the packages.
The next maintainer could adopt the packages then.

I think this is simple, doable and does not require building trust
with external repositories which I think is not a great idea
generally.

Cheers,
Balint


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAK0OdpwrryX4DJhAK9=0TrRmxRx8RwE4WmQR4kbGXD1hrT1c=q...@mail.gmail.com

Re: lowering severity of bugs not tracked by release team

[Bálint Réczey]

Hi Mike,

First, I had to cancel the upload because of too strict reverse
dependencies. Dear fellow JavaScript maintainers please figure out a
less strict dependency graph because every otherwise fully compatible
libv8 update would break several packages.

2014-12-21 2:13 GMT+01:00 Michael Gilbert mgilb...@debian.org:
 On Sat, Dec 20, 2014 at 7:52 PM, Bálint Réczey wrote:
 The proper severity of this bug is grave as set by Moritz IMO. I'm
 restoring it wearing my maintainer hat.

 It's not really constructive arguing over severity, so that's fine.
I appreciate the work done by the Security Team but to work together
we have to know what actions can be taken by the Security Team.
Increasing severity of bugs is business as usual and perfectly
reasonable, but _decreasing_ the severity _based on the availability
of security support_ was crossing a line IMO. It seems the line was
there based on Jonas' and Adam's email.
To clarify my position the Security Team can and is expected to
decrease the severity in case a security bug's impact turns out to be
less than originally expected but in this particular case this rule
does not seem to be applicable.

 You've saved yourself from needing to write an unblock request.

 The problem still remains that the backlog of libv8 security issues
 never get fixed (except for a new upstream every now and then), so
 treating this one as RC but not the others is rather inconsistent:
 https://security-tracker.debian.org/tracker/source-package/libv8
 https://security-tracker.debian.org/tracker/source-package/libv8-3.14
If there were bugs opened for those CVE-s those should have been
opened with grave severity, too.


 Note that unimportant there indicates lack of security support for the 
 package.
This is confusing. Please don't mark them as unimportant because in
this context unimportant is defined differently.

https://security-tracker.debian.org/tracker/status/unimportant :
This page lists packages that are affected by issues that are
considered unimportant from a security perspective. These issues are
thought to be unexploitable or uneffective in most situations (for
example, browser denial-of-services).


 If there is interest in security support for libv8, that is a good
 thing, but a lot more needs to be done for that to be true.
Well, there is a long way to go, I agree.

Thank you for helping the Security Team and keeping the bugs and CVE-s updated.

Cheers,
Balint


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAK0OdpwZt5H+j4fFX=6VctOi7TNZEMfJ=BiS9JKXhAR=R=k...@mail.gmail.com

Re: lowering severity of bugs not tracked by release team

[Bálint Réczey]

Control: severity -1 grave

Hi Mike,

2014-12-20 20:57 GMT+01:00 Michael Gilbert mgilb...@debian.org:
 On Sat, Dec 20, 2014 at 6:15 AM, Adam D. Barratt wrote:
 On Sat, 2014-12-20 at 11:48 +0100, Jonas Smedegaard wrote:
 [sent again, cc correct list address this time]

 Quoting Michael Gilbert (2014-12-20 11:06:47)
  On Sat, Dec 20, 2014 at 4:59 AM, Balint Reczey wrote:
  On Fri, 19 Dec 2014 21:11:10 -0500 Michael Gilbert wrote:
  control: severity -1 important
 
  There is no security support for libv8 in jessie, so security issues
  aren't RC.
  Could you please add some links to explain that?
  I was about to fix this issue in an NMU after double-checking the
  fix.
 
  Severity doesn't say anything about whether or not a bugs can be
  fixed, so you can still do that.  Anyway it was decided recently on
  the security team ml.

 I'm not aware of it having been decided that the security team were the
 arbiters of release criticality in such situations.

 The severity was bumped to grave by Moritz about a month ago, likely
 to get the libv8 maintainers to actually pay attention to their vast
 volume of unaddressed security issues.

 Now that it's been decided that libv8 won't get security support in
 jessie, it seems perfectly reasonable to move back to the original
 severity, which is important.
The proper severity of this bug is grave as set by Moritz IMO. I'm
restoring it wearing my maintainer hat.
I have also checked if the fix changed the ABI using objdump (did not
change it) and uploaded a fixed version to DELAYED/2.
The fix can be found in the usual packaging repository.

Cheers,
Balint


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cak0odpy6skfv+h+coqi_95e31r_msxvxty2cqrq4n4hzxsj...@mail.gmail.com

Being part of a community and behaving

[Bálint Réczey]

Dear Josselin,

I have just noticed your blog post on planet.debian.org:
https://np237.livejournal.com/34598.html

I would like to ask you to resist the temptation of publishing similar posts.
It makes fun of part of our community which you are well aware of and
it also shows corpses which probably did not ring a bell in you.

None of those show good taste and by having it aggregated on
planet.debian.org it shows the whole project in bad light, too.

Thanks in advance,
Balint


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cak0odpxmkyqxinuc+l+35x0gole04ye37wwv5ug3ynsz4sm...@mail.gmail.com

Re: Being part of a community and behaving

[Bálint Réczey]

Hi Norbert,

2014-11-13 13:23 GMT+01:00 Norbert Preining prein...@logic.at:
 On Thu, 13 Nov 2014, Bálint Réczey wrote:
 I have just noticed your blog post on planet.debian.org:
 https://np237.livejournal.com/34598.html

 You lack any sense of humor, really!
I clearly sensed the humor as I wrote in the part you cut.


 Although I am a strong opponent of systemd, I had to laugh out loud
 on that one, actually love it.

 Sad to see people like you that are complete bare of any
 acceptance for ironic, sarcastic humor.
I love irony and sarcasm, but I don't think planet.debian.org is the
right place for the mentioned content.
9gag for sure.

Cheers,
Balint


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAK0OdpxUtKLt-K6E_YOBZkwNGQPHClN=qzhhym19rqov+...@mail.gmail.com

Re: Two years later and still no netatalk3 in jessie?

[Bálint Réczey]

Hi Adrian,

2014-11-09 10:48 GMT+01:00 Adrian Knoth a...@drcomp.erfurt.thur.de:
 On Thu, Aug 28, 2014 at 01:21:04PM -0400, Igor Bernstein wrote:

 - jessie freeze happens in 2 months

 Happened in the meantime :-/

 2014/8/4 - Adrian updated the package to 3.1.3
 adi's package (currently @ 3.1.3):
 https://github.com/adiknoth/netatalk-debian

 JFTR, I'm at 3.1.6.


 The whole situation reminds me of wine, where Debian shipped the same
 outdated version for multiple releases.

 Even downstream distributions are suffering:

  
 http://raspberrypi.stackexchange.com/questions/23985/why-is-netatalk-not-updated


 I'd say get some devs behind this, call the package netatalk3 and ship
 it in parallel. I had it running for months, upstream had worked on it
 for years, it's not that this is bleeding edge or untested.
IMHO the proper way of putting this package into focus is asking the
maintainers to file an RFH bug if you don't want help yourself.
Helping yourself can be submitting patches through BTS, packaging the
new version and uploading it to mentors.debian.net or even hiring
someone to do it for you.


 jessie without netatalk3 would be embarrassing at best, but more
 importantly, it would be frustrating for everyone who wants to use their
 Linux file servers as a time machine backup.
Most probably Jessie will not contain netatalk 3, but having it in
jessie-backports would be almost as good as having it in jessie.


 CC debian-devel for additional momentum. Please stop CCing this bug in
 case this turns into another bike shedding discussions on the ML.
Please try the RFH [1] way instead of CC-ing debian-devel.
Packages/bugs needing more attention is business as usual and the RFH
way is the standard procedure for dealing with it.

personal opinion
While the procedure for ensuring better care for our packages (filing
RFH, RFA, O bugs) do exist, we, maintainers are not proactive enough
using the procedures.
If you are a fellow DD/DM/sponsored uploader, please take a look at
the packages BTS lists under your name and think for a moment if the
package needs help or a new maintainer.
/personal opinion

Cheers,
Balint

[1]https://www.debian.org/devel/wnpp/#l2


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAK0OdpxrJr+MNTkJKDu0stoUC3LEeZP6J2m=bofc00fcnxu...@mail.gmail.com

Re: Internal compiler error

[Bálint Réczey]

Hi Frederic,

2014-10-04 10:50 GMT+02:00 Colin Watson cjwat...@debian.org:
 On Sat, Oct 04, 2014 at 07:24:03AM +, PICCA Frederic-Emmanuel wrote:
 Hello, I got an FTBFS due to an internal compiler error.

 should I fill a bug against gcc ?

 Yes.  Please see:

   /usr/share/doc/gcc/README.Bugs

 You'll need to follow those instructions on a porter box, or ask your
 sponsor to do so if you don't have direct access.

 should I fill also an RC bug for my package ?

 I would not generally do so for ICEs, unless you think there's some
 possibility of a reasonable workaround (there often isn't).  You may
 find it necessary to ask for the mipsel binaries to be removed from the
 archive if a solution isn't forthcoming, so that newer versions can
 progress to testing.
Probably it would be better to depend on a working compiler (gcc with
version/clang) temporarily until the ICE is fixed in the default one
to keep the binary package in the archive.

Cheers,
Balint


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAK0Odpy=ncbl9rnsevxvgsrx4y0ae6kq91qw5hnv6ozn-kh...@mail.gmail.com

Re: [bal...@balintreczey.hu: Accepted xbmc 2:13.2+dfsg1-2~exp0 (source all amd64) into experimental

[Bálint Réczey]

Hi David,

2014-09-30 13:35 GMT+02:00 David Weinehall t...@debian.org:
 The latest upload of xbmc seems a bit botched; this is the
 changelog in its entirety:


  xbmc (2:13.2+dfsg1-2~exp0) UNRELEASED; urgency=medium
  .
*

 Now, there is nothing wrong with terse and succinct changelogs,
 but I'd say this is a bit *too* terse, and not at all succinct.
:-)
Thanks for pointing this out. I'll upload a fixed version soon.
Luckily the content of the package content was OK, I just forgot about
the last update to the changelog.


 Also, should the builders even accept packages that has an invalid
 distribution specified (in the most recent changelog entry, that is)?
I think rejecting those during upload would be a good idea.

Cheers,
Balint


 Filtering out UNRELEASED and packages with an empty changelog would
 prevent at least some premature uploads.


 Kind regards, David Weinehall
 --
  /) David Weinehall t...@debian.org /) Rime on my window   (\
 //  ~   //  Diamond-white roses of fire //
 \)  http://www.acc.umu.se/~tao/(/   Beautiful hoar-frost   (/



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAK0OdpzHzU3vAhHjoXLS-qiz0-SfMwcwMFi5O8HJJxaBgBNE=w...@mail.gmail.com

Re: Two-minute(!)-survey on motivation and free time contribution of open source developers

[Bálint Réczey]

Hi,
2014-08-31 17:42 GMT+02:00 Paul Wise p...@debian.org:
 On Sun, Aug 31, 2014 at 6:53 AM, Stefan Kullack wrote:

 It would be fantastic if you could spend two minutes on three simple 
 questions!

 Here is the link to the survey: https://de.surveymonkey.com/s/MFKXYLP

 You might get more feedback if you weren't using a proprietary SaaSS
 (service as a software substitute) that also causes privacy violations
 by asking users' browsers to report to the proprietary privacy
 invading Google Analytics service.
I would happily take this survey if I could do it without enabling
JavaScript on the page.
It this was the first survey question it is a pretty clever setup :-)

Cheers,
Balint


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAK0OdpyDTtv7r5OXVSAd3Xynn-vuFrDrrT6gJ0H2aF7g=zt...@mail.gmail.com

Re: JavaScript usage (was: Two-minute(!)-survey on motivation and free time contribution of open source developers)

[Bálint Réczey]

Hi Octavio and All,

2014-08-31 19:21 GMT+02:00 Octavio Alvarez alvar...@alvarezp.ods.org:
 On 08/31/2014 10:03 AM, Bálint Réczey wrote:
 Hi,
 2014-08-31 17:42 GMT+02:00 Paul Wise p...@debian.org:
 On Sun, Aug 31, 2014 at 6:53 AM, Stefan Kullack wrote:

 It would be fantastic if you could spend two minutes on three simple 
 questions!

 Here is the link to the survey: https://de.surveymonkey.com/s/MFKXYLP

 You might get more feedback if you weren't using a proprietary SaaSS
 (service as a software substitute) that also causes privacy violations
 by asking users' browsers to report to the proprietary privacy
 invading Google Analytics service.
 I would happily take this survey if I could do it without enabling
 JavaScript on the page.
 It this was the first survey question it is a pretty clever setup :-)

 Why don't you use JavaScript? I also don't like enabling JavaScript in
 my browsers but other than my personal reasons I have no arguments
 coming from somebody else.

 How do you currently cope up with pages with JavaScript? I use Chrome
 and the Quick JavaScript Switcher plugin.

 Do you have a particular concept regarding JavaScript or scripting in
 documents, or is it just for a practical purpose?
I use NoScript and enable the minimal set of JavaScripts for every
page they need to run. Most probably this is overkill and I take this
request back. I just felt that for a few checkboxes and radio buttons
it is overkill to run JavaScript.

Cheers,
Balint


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cak0odpw3xxk_bc-bl2lz17vrn4tmifrvav2ifd5gtxc0sr-...@mail.gmail.com

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Bálint Réczey]

Hi Nicolas,

2014-08-16 17:11 GMT+02:00 Nicolas George geo...@nsup.org:
 L'octidi 28 thermidor, an CCXXII, Bálint Réczey a écrit :
 Using Gerrit and file ownersip are not mutually exclusive. Gerrit
 can be configured to automatically invite the right people for review
 based on the changed path. We recently migrated to Gerrit at the
 Wireshark project and it helps a lot in coordinating the reviews.

 I am afraid this discussion on Gerrit or other similar tools is pointless:
 this is trying to solve a human problem with technical means: it never
 works.
I did not want to sell Gerrit over mailing-list discussion because the
work-flow is something which should be chosen by the development team
and not outsiders, but wanted to show that tools can help enforcing
some parts of the work-flow.

On the human problems vs. technical means questions I think we have
different opinions. Technical means are exceptionally great tools for
solving _some_ human problems. If the human problem is being not
satisfied with peers' behavior of not following a specific work-flow a
toll which enforces the work-flow would solve it. Making mistakes is
an other (mostly) human problem and we have lintian for example which
helps pointing them out.


 Actually, I believe all this peer-review business to be a red herring. On
 the FFmpeg side, most patches except the very simple ones are sent to the
 mailing-list for peer-review, even patches by people with commit rights
 working on their own code; they do so not because a rule states they have
 too but because this is the best thing to achieve good code. On the other
 hand, I remember having seen patches somewhat rushed through the mandatory
 review on libav-devel and applied when someone else still had remarks; I
 have not kept tabs on that though.

 The real issue between the mandatory peer-review on the mailing-list is,
 IMHO, control of the project orientation. Not is this patch correct? but
 do we want this patch?.

 If you are involved in the project, it is very obvious that both branches
 have rather opposed views on the project orientation: libav has made a point
 of trimming unnecessary features and rejecting new ones while FFmpeg kept
 them and added some.
IMO the trimming/rejecting strategy is not something which would ever
make Libav popular among developers/users and this is how we ended in
the current situation. While Libav's communicated release strategy can
attract integrators and distributions like Debian, FFmpeg attracts
developers/users of software based on Libav/FFmpeg due to more
features.
Sticking to those core strategies the two forks will compete forever
until one of them give up - which I see unlikely to happen voluntarily
- and users will keep complaining about Libav's missing features to
distributions' maintainers where FFmpeg is not packaged.

I think the best way out of this situation would be relaxing the
review requirements on Libav's side and letting not-yet-proven of
FFmpeg features in through an experimental/staging phase. If FFmpeg
devs could collaborate with them this way the two forks could be
converged and finally merged and the combined team could maintain a
lot better media library than the current forks are separately.

Cheers,
Balint


 A few examples:

 * Libav removed ffserver, FFmpeg kept it, trying to unbreak it. The commit
   message said appears simpler to write a new replacement from scratch,
   but in the meantime, users are left without the feature.

 * Libav removed the framerate detection code, FFmpeg built on it to handle
   it in filtering too. I do not find them right now, but I have found a few
   files that avconv wanted to encode at an insane frame rate while ffmpeg
   correctly guessed; and right now, -vf fps does not work alone with very
   common formats in avconv.

 * Libav removed the keyboard interaction (Press [q] to stop) while FFmpeg
   extended it.

 Beyond these obvious cases, FFmpeg has gained quite a few features that, I
 am pretty certain of it, would not have been accepted into libav: the concat
 demuxer (has been called hack on the mailing-lists IIRC), the lavfi
 sources made for testing, support for some obscure format through an
 external library, subtitles hard-burning, etc.

 The most galling in this issue is that there is no clear decision behind
 this orientation. The fork's manifesto stated that everyone was equal
 amongst equals, with or without commit rights, but the people who do have
 the commit rights are few and of a common mind, they can just give the cold
 shoulder to proposed changes that do not suit their personal view of the
 project.

 Considering these differences in policy, I do not believe the fork can be
 merged. Speaking as someone who proposed a few of these unnecessary
 features, because they were fun or immediately useful, I would not like to
 work on a project that would reject them by principle. But I can recognize,
 for someone who needs serious professional software, the need

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Bálint Réczey]

Hi Russ,

2014-08-16 18:59 GMT+02:00 Russ Allbery r...@debian.org:
 Cyril Brulebois k...@debian.org writes:
 Russ Allbery r...@debian.org (2014-08-16):

 None of this is why libav and FFmpeg can't both be in the archive.
 They can't both be in the archive because both the release team and
 the security team have said that they're not interested in trying to
 support both, due to the amount of work involved.

 the release team only has a say on what ends up in testing (and then
 in stable); it cannot, and AFAICT hasn't tried to, block ffmpeg from
 entering the archive. FTP masters have the control over the archive
 as a whole.

 Sorry, yes, good point.  I should have been clearer.  I assume the goal
 was to get both into a stable release.  If people wanted to upload FFmpeg
 only to unstable without propagation to testing or making it part of a
 release, that's a possibly different situation with different tradeoffs
 and issues involved.
For now the target is not stable, but unstable/experimental. Both the
Security and Release Teams could keep an RC bug on the package until
they are fine with letting it into testing.

Cheers,
Balint


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cak0odpzp7jri7zwhd5t_bh+trbtznnx139lequ-+rkwkrbw...@mail.gmail.com

Bug#758245: ITP: libcli-framework-perl -- standardized, flexible, testable CLI applications framework for Perl

[Bálint Réczey]

Package: wnpp
Owner: Balint Reczey bal...@balintreczey.hu
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org

* Package name: libcli-framework-perl
  Version : 0.05
  Upstream Author : Karl Erisman keris...@cpan.org
* URL : https://metacpan.org/release/CLI-Framework
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : standardized, flexible, testable CLI applications
framework for Perl

 CLI::Framework (CLIF) provides a framework and conceptual pattern for
 building full-featured command line applications. It intends to make
 this process simple and consistent. It assumes the responsibility of
 implementing details that are common to all command-line applications,
 making it possible for new applications adhering to well-defined
 conventions to be built without the need to repeatedly write the same
 command-line interface code.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAK0OdpzpmTJf2Xc-6R-CVE7U4B7j=tfoFW5ON=tppagd368...@mail.gmail.com

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Bálint Réczey]

Hi,

2014-08-15 14:20 GMT+02:00 Michael Niedermayer michae...@gmx.at:
 On Fri, Aug 15, 2014 at 02:53:09PM +0800, Thomas Goirand wrote:
 On 08/14/2014 11:59 PM, The Wanderer wrote:
  On 08/14/2014 11:27 AM, Thomas Goirand wrote:
 
  On 08/13/2014 07:53 AM, Kieran Kunhya wrote:
 
  On 08/13/2014 06:30 AM, Michael Niedermayer wrote:
 
  Also ive offered my resignation in the past. I do still offer to
  resign from the FFmpeg leader position, if it resolves this split
  between FFmpeg and Libav and make everyone work together again.
 
  Why not just take the offer, and move on?
 
  Probably because of the condition he attached to it, which also dates
  back to the arguments preceding the original split:
 
  The part i insist on though is that everyone must be able to work
  on their code without people uninvolved in that specific parts
  maintaince or authorship being able to block their work.
 
  In other words, as I think I understand it from the discussion back
  then: people not involved with a particular area of the code can't NACK
  the work of someone who is working on it, and someone who works on a
  particular area of the code doesn't have to wait on review of people who
  aren't involved with that area of the code.
 
  Since one of the motivations of the people behind the libav side of the
  split seems, IIRC, to have been no code gets in without having been
  reviewed by someone other than the author, this was apparently deemed
  an unacceptable condition.

 Hum... Well, to me, what's important is that the code gets
 peer-reviewed.

 Yes, the tricky part in FFmpeg and Libav in relation to this is that
 theres quite a bit of code that is only well understood by a single
 person even if you would combine both projects together.
 So if that person posts a patch for review, theres noone who could
 do a real review
This situation is not totally unique to FFmpeg/Libav. IMO in this
real-life situation peers can do a best-effort review and people doing
so would sooner or later will get familiar with those parts of the
code as well.
In case of a widely used library like this the biggest issue is
breaking the ABI or modifying the ABI in a way which does not align
with the team's vision about the ABI roadmap. That type of change can
be pointed out by less experienced developers, too.
Internal regressions in the code can be easily fixed even if they are
not discovered during testing and enter the release.



 Setting-up something like gerrit may help, as it can be
 setup in a way that review becomes mandatory. Then discussing who's
 core-reviewer and can approve this or that part of the code can be setup
 within gerrit. This should be discussed, and setup based on technical merit.

 Not commenting about gerrit as i dont have experience with it, but
 FFmpeg currently uses a simple file in main ffmpeg git that lists
 which part is maintained by whom, and these developers would in the
 rare case of a dispute have the final say in each area.
Using Gerrit and file ownersip are not mutually exclusive. Gerrit
can be configured to automatically invite the right people for review
based on the changed path. We recently migrated to Gerrit at the
Wireshark project and it helps a lot in coordinating the reviews.

Cheers,
Balint


 OTOH, Libav early deleted their forked version of this file, and
 iam not aware of any replacement. But others should explain how it
 works in Libav ...



 Having a NACK review is often disappointing. It goes the wrong way if
 there's only a NACK with no comments on how to improve things, so that
 the code becomes acceptable.

 Absolutely everyone should *always* be able
 to leave comments, be it positive or negative.

 yes, i fully agree and this also was always so in FFmpeg. In that
 sense everyone is welcome to subscribe to ffmpeg-devel and review and
 comment patches. That of course includes Libav developers and everyone
 else. And more reviewers would also certainly help, so yeah anyone
 reading this and wanting to help review patches, you are welcome!

 Thanks

 [...]
 --
 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

 it is not once nor twice but times without number that the same ideas make
 their appearance in the world. -- Aristotle


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cak0odpwaj1irea2ymdznjqwkw+hhep3yg-vvuy8mp8hje3d...@mail.gmail.com

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Bálint Réczey]

2014-08-14 13:58 GMT+02:00 Stefano Sabatini stefa...@gmail.com:
 On date Wednesday 2014-08-13 16:27:20 +0200, Attila Kinali encoded:
 On Wed, 13 Aug 2014 00:30:05 +0200
 Michael Niedermayer michae...@gmx.at wrote:

  I never understood why people who once where friends
  became mutually so hostile

 You should know that better than anyone else!

 You still claim to be my friend, yet you said and did things
 that i have not seen from my enemies, let alone from my friends.
 To this day, after 3 years, i still get accused by random people
 of thing i supposedly have done against FFmpeg and the spirit
 of open source. After 3 years i still have to defend myself against
 these baseless attacks!

 If you trully want to mend ways, then you and your fellow FFmpeg
 developers should stop this constant spreading of lies, this
 defamation campaing against libav and its developers that has
 been going on for the last 3 and a half years and show at least
 the minimum respect you would show to a stranger you meet on the
 street. Until you do this, i see very little chance for a healthy
 cooperation.

 Please refrain from claiming other people are spreading lies,
 especially with no specific references (and this is not the place
 where to discuss such things).

 As for me, I don't consider Libav developers neither friends nor
 enemies. We reached a point when we got two different projects with
 different policies, culture, and guidelines. Then you should be aware
 that the way the Libav fork was created was hostile towards FFmpeg, so
 you shouldn't be surprised that there was (and still there is) a
 perceived hostility between the two projects. If you or other Libav or
 FFmpeg developers want the two projects to collaborate more, this can
 be discussed, possibly with *specific* proposals, but again,
 debian-devel is not the right place where to discuss such things.
I have no problem with FFmpeg and Libav developers discussing
collaboration on debian-devel especially if they finally sit together
and find a way in which they could join efforts after years of working
in separation.
This would be Legen... ...dary. :-)

Cheers,
Balint


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cak0odpwp7rzzwmpkpwc9txtb2na3zp7bb8t2mdgktiztxfd...@mail.gmail.com

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Bálint Réczey]

Hi,

2014-08-08 20:06 GMT+02:00 Andreas Cadhalpun andreas.cadhal...@googlemail.com:
 Hi Reinhard,


 On 08.08.2014 14:29, Reinhard Tartler wrote:

 On Fri, Aug 8, 2014 at 7:13 AM, Matthias Urlichs matth...@urlichs.de
 wrote:
 I intended to come up with a more timely full response, but I just
 didn't get to it so far.


 Thanks for explaining your point of view here.


 For now, please refer to http://lwn.net/Articles/607662/,


 Have a look at: http://lwn.net/Articles/608040/

 I was not there, when the FFmpeg/Libav split happened and I don't want to
 judge, whether it was a good thing or not. But it clearly caused a lot of
 bad blood between the developers involved, which in my opinion hurts the
 development of the multimedia framework in recent times.


 http://codecs.multimedia.cx/?p=370 (rather old, but still true), and


 If these features weren't used, they wouldn't have been developed.
 And many new features have been added to FFmpeg after that post.


 http://codecs.multimedia.cx/?p=674 (recent update on that matter)


 Let me quote from there:
 But that’s not what kills the fun, “security holes” do.

 With an advance of automatic fuzz tools it’s easy to generate millions of
 damaged files that crash your decoder and yet there are no tools for
 generating correct patches. Fixing those crashes is tedious, requires a lot
 of thinking (should I disable it? will it affect decoding correct files?
 etc.) and in other words not fun at all.

 That seems as if he doesn't want to continue Libav development, because
 fixing security issues is tedious work.
 It has basically nothing to do with whether FFmpeg is of good quality
 security wise or not, or a good or bad competitor against Libav.


 Regarding Marco's argument that libav had few friends, well, let me
 point to https://medium.com/libre-parole/libav-is-beautiful-4c1a2c886948
 for instance.


 One person thinking that the code is 'beautiful' is no convincing argument.
 The number of people expressing their interest in having FFmpeg back in
 Debian is a lot more convincing.


 IMHO the best idea at this point would be to toss out libav, and rebuild
 the rdeps with ffmpeg. Now, before it's too late for jessie.


 I think that is totally out of question: Uploading FFmpeg to our
 archive will break the Debian archive so hard that it will take months
 to get everything back to testing, if it works at all.


 Let me repeat what I wrote in my initial mail in this thread:
 Having FFmpeg in the Debian archive breaks absolutely *nothing*, but it
 gives developers and users a choice between the two.

 Even if Libav were to be removed, a transition to FFmpeg could be rather
 smooth, as all the necessary patches already exist.
 But you're right that the time to test the resulting packages is getting
 rather short for the coming freeze.

 Still it can make sense for packages that are tested with FFmpeg upstream
 and have known issues with Libav.

 So if you and the other Libav maintainers were to support the idea of having
 both, the security and release teams could perhaps be convinced to allow
 that. This has been my goal from the beginning and I hoped that would be
 appreciated.


 To the best of my knowledge, there are only two high-profile projects
 that play hardball to require FFmpeg: Mplayer and mythtv. Neither of
 those do that (again to the best of my knowledge) mainly because of
 technical but rather very political reasons. The case of mplayer has
 been elaborated extensively in
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732159#79 (see the
 following discussion with Reimar - my conclusion from that is while
 technically possible, nobody wants to make mplayer work with Libav -
 and that's why it was removed, not because of the FFmpeg dependency).
 For Mythtv I can only say that they didn't even bother engaging any
 discussion.


 That FFmpeg has more features is a rather technical argument.

 Note that also many other projects are developed mainly with FFmpeg, they
 just happen to not break completely when compiled against Libav.

 For example, mpv prefers FFmpeg for good reasons:
 Although mpv attempts to work well with both FFmpeg and Libav, FFmpeg is
 preferred in general. This is simply because FFmpeg merges from Libav, and
 seems to have more features and fewer bugs than Libav. [1]

 These features are actually requested by users, see e.g. [2].


 (All) other high-profile downstream projects, including VLC or XBMC
 (now Kodi) work demonstrably just fine with Libav. Sure, FFmpeg may


 Just fine? Did you see the bugs I mentioned in my initial mail?

 And how does it come that XBMC needs the '--enable-libav-compat' configure
 option, which then uses code from lib/xbmc-libav-hacks, to build against
 Libav?
Being the xbmc maintainer I feel being addressed and let me share my
POV regarding XBMC. :-)
XBMC works with Libav for most use-cases while it fails in the rest,
notably it can not use VDPAU acceleration which is being
(understandably) 

Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian

[Bálint Réczey]

2014-08-09 13:41 GMT+02:00 Jonas Smedegaard d...@jones.dk:
 Quoting Bálint Réczey (2014-08-09 11:38:54)
 XBMC works with Libav for most use-cases while it fails in the rest,
 notably it can not use VDPAU acceleration which is being
 (understandably) complained about very often (#742896). Another issue
 is Libav crashing on bad input which makes XBMC/Libav unusable in PVR
 configurations when signal is corrupted sometimes (#741170).

 Ok, so you  know factually that some things are broken when linking XBMC
 with Libav instead of XBMC-FFmpeg.
Well, it depends on the definition of factually. I could not test the
VDPAU issues myself. :-)



 Upstream makes sure all their use-cases work well with FFmpeg and not
 interested in Libav-related issues.

 According to XBMC, they only make sure their code works with
 XBMC-FFmpeg.


 I can't fix the problems because I don't have any HW reproducing them,
 and I don't get help from Libav upstream/maintainers either in fixing
 those issues.

 That sounds to me like you do not factually know if XBMC will be broken
 also when linked against FFmeg (you only really know about XBMC-FFmpeg).
Since XBMC switched to vanilla FFmpeg from their internal fork I would
be really surprised if XBMC did not work with the proposed new FFmpeg
packages. -dmo packages are built with external FFmpeg, too...
If this test is a deal-breaker for accepting FFmpeg into experimental
I can provide binaries for testing but probably most curious DD-s
having the right HW would be able to test if my theory is right.



 I would like to have flawlessly working XBMC in Debian as well, but it
 can't happen without fixing the Libav issues I mentioned above or
 letting FFmpeg entering Debian.

 I do understand how it is easier for you to link XBMC against FFmpeg
 than against Libav, since FFmpeg has similar/same API as XBMC-FFmpeg,
 but it seems to me that you are jumping to conclusions when stating that
 linking against (non-XBMC-)FFmpeg will make XBMC work flawlessly.
I would say it is not a mathematically correct reasoning, but a strong
expectation supported by observations.
Prove me wrong if you really think I'm missing something, I will stand
corrected. I made falsifiable statements.

By flawlessly I mean very close to upstream's expectations and
specifically fixing VDPAU and PVR issues I mentioned earlier.

Cheers,
Balint


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cak0odpwe3+f3xadthd+vy9p-gxnz_gwlvew9cksbp80dxa8...@mail.gmail.com

Re: Re: people.debian.org will move from ravel to paradis and become HTTPS only

[Bálint Réczey]

2014-07-17 2:20 GMT+02:00 brian m. carlson sand...@crustytoothpaste.net:
 On Wed, Jul 16, 2014 at 11:43:17PM +0100, Steven Chamberlain wrote:
 Some sites (I mean, deployments) like to use a caching proxy, especially
 if many machines use the same resource, and/or bandwidth is scarce.  Or
 even just one machine accessing the same resource often.  Maybe this
 won't apply to anything particular on people.d.o, but certainly a lot of
 websites are breaking this recently by becoming HTTPS-only.

 Unfortunately, many of these proxies are broken.  The Squid version in
 wheezy doesn't support HTTP/1.1, so trying to use chunked encoding or
 100 Continue (which is required for certain applications[0]) simply
 doesn't work.  And simply not working is one of the best failure cases
 for broken proxies.  Using HTTPS ensures that the broken proxy problem
 is gone.

 I'm curious to know the rationale for shutting down HTTP access, because
 if it is to generally protect web browsers doing web-based login and
 using cookies, that would typically be covered by HSTS.  And the
 privacy-concious may be using the HTTPS Everywhere add-on.

 I can't speak for DSA here, but I some of the reasons that I went
 HTTPS-only is that certificates are relatively cheap, pervasive
 monitoring is not going away, crypto is so cheap computationally on most
 platforms that there's no reason not to, and broken proxies suck.
Those are all very good reasons for enabling HTTPS, but none of those
serve as a good reason for disabling HTTP.
It someone uses a broken proxy he/she can fix it or switch to https,
but why are others required to switch?
I for one would be unhappy with losing the ability of using a caching
proxy for APT repositories hosted on p.d.o, I saved many GB-s of
bandwidth this way.

I have added debian-admin@l.d.o to CC since according to the email
starting this thread this is the address where questions should be
sent and apparently this thread did not get any attention of the Admin
Team.

Cheers,
Balint


 [0] Git pushes over HTTP with Kerberos, among many others.

 --
 brian m. carlson / brian with sandals: Houston, Texas, US
 +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
 OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAK0OdpwRVSFPNBVdN=q2OyF5QNULhV+VuRQNayr0T=dizxw...@mail.gmail.com

Re: people.debian.org will move from ravel to paradis and become HTTPS only

[Bálint Réczey]

2014-07-15 21:39 GMT+02:00 Philipp Kern pk...@debian.org:
 On 2014-07-15 16:00, Thorsten Glaser wrote:

 Martin Zobel-Helas dixit:

 Furthermore, we will change the people.debian.org web-service such that
 only HTTPS connections will be supported (unencrypted requests will be
 redirected).

 […]

 Take it as a heads-up to maybe move stuff elsewhere, if it needs http
 (e.g. APT repos work well via http since they use PGP for signatures).

 Actually, this will break most DDs’ APT repositories because
 apt-transport-https is usually not installed.


 Pointing machines to a non-mirrored SPoF running on donated project
 resources was bound to be not such a great idea anyway.
Which place would be better for hosting DD's APT repositories? I had
the impression that p.d.o were the usual place for them and it served
quite well.
I would also be interested in keeping plain HTTP to not break
repositories (including mine :-)).

Somehow Steve's question regarding the rationale behind disabling HTTP
got cut out from email responses so let me raise it again:
Why is it important to disable HTTP?
Could it be kept enabled for APT repositories following some special
directory structure like http://p.d.o/~user/ppa/* ?

2014-07-14 0:19 GMT+02:00 Steve Langasek vor...@debian.org:
 Hi Martin,

 On Sun, Jul 13, 2014 at 10:13:10PM +0200, Martin Zobel-Helas wrote:
 Furthermore, we will change the people.debian.org web-service such that
 only HTTPS connections will be supported (unencrypted requests will be
 redirected).

 Could you elaborate on why people.d.o will enforce https?  If http
 connections are still allowed, this doesn't provide any protection from a
 MITM attack for most users; and the contents of people.d.o are not generally
 security sensitive.  Is this part of a broader effort by DSA to increase use
 of https by default as a deterrent to large-scale traffic sniffing?


Cheers,
Balint


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cak0odpymbo7gmge3khx08wtfu3bqz+just3tzvnj58ztq0a...@mail.gmail.com

Re: Automatically dumping test-suite.log on make check failure

[Bálint Réczey]

2014-05-08 20:49 GMT+02:00 Marcin Owsiany porri...@debian.org:

 2014-05-08 19:33 GMT+02:00 Guillem Jover guil...@debian.org:

 Hi!

 On Thu, 2014-05-08 at 19:10:48 +0200, Marcin Owsiany wrote:
  Does anyone know a way to make the automake-generated test suite scripts
  cat
  the test-suite.log to stderr on failure? It just reports which tests
  failed but
  hides the actual messages. This is most annoying on buildds which then
  promptly
  remove the whole build dir, and one has to then tediously find a porter
  box,
  set up schroot, fetch the package, install build-deps, run the build and
  then
  finally manually cat the log. Example:

 Yes, pass VERBOSE=1 to the «make check» call. This was brought up
 recently in the following thread:

   https://lists.debian.org/debian-devel/2014/04/msg00322.html


 Awesome, thank you!
I'm with Joey on this.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=680686#29

IMO Debian buildds should set DH_VERBOSE=1 and VERBOSE=1 instead of
making various parts of debhelper more verbose.
This would fix a range of problems, not just the missing test logs.

Cheers,
Balint


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cak0odpyzzf3yod4oo1awnc6ota_ywaja1kxarg-rm9qxfg7...@mail.gmail.com

Re: Ghostscript licensing changed to AGPL

[Bálint Réczey]

Hi,

2014-05-07 14:37 GMT+02:00 Thorsten Glaser t...@debian.org:
 On Wed, 7 May 2014, Ian Jackson wrote:

 Yes.  But this isn't as bad as you think, because the source
 availability requirement exists only if you modify the AGPL'd
 software.

 Which you may want to do, in order to patch a security issue
 you just found, locally, before filing it upstream.
In my interpretation in this case I would have some reasonable time to
comply, i.e.
I don't have to publish all 0days on my site if I run AGPL-covered software.

 Or because you’re a user of Debian and used to be able to do
 just that.
Hmm, as a Debian user I'm used to respecting the license of any
software being it BSD, GPL or AGPL...

 This basically fails “Licence must not be specific to Debian”
 if you assume the “did not modify so this clause does not
 apply” case.
This reasoning could have been brought up in the context of
relicensing previously BSD licensed software under GPL, and I think it
would have been invalid in that case, too.

Cheers,
Balint


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cak0odpwo23jp5c7oe8olq1z6cbo5cjs-usexnuzyxx6+g_b...@mail.gmail.com

Re: Proposing amd64-hardened architecture for Debian

[Bálint Réczey]

2014.04.20. 7:47, Riku Voipio riku.voi...@iki.fi ezt írta:

 On Sat, Apr 19, 2014 at 02

 On Sat, Apr 19, 2014 at 02:06:45PM +0200, Bálint Réczey wrote:
  Hi Riku,
 
  2014-04-19 13:26 GMT+02:00 Riku Voipio riku.voi...@iki.fi:
   On Tue, Apr 15, 2014 at 12:00:33PM +0200, Balint Reczey wrote:
   Facing last week's Heartbleed [1] bug the need for improving the
   security of our systems became more apparent than usually. In Debian
   there are widely used methods for Hardening [2] packages at build time
   and guidelines [3] for improving the default installations' security.
  
   Riding the Heartbleed publicity wave seems unwise, unless you can
   propose a hardening flag that would have protected users from
   Heartbleed. Else, Heartbleed merely serves on a example
   how wallpapering problems over with hardened binaries often
   doesn't help you at all..
  
   Considering that most issues protected by compiler hardening are
   also detectable by static/dynamic code analysis, a more effective
 security
   measure would be to spend time with clang static analyzer, valgrind,
 trinity
   and other tools... or actualy reviewing patches that security critical
   projects recieve.
  Thank you for bringing this up now.
  I have just managed to compile openssl, without the fix for the
  Heartbleed test but with -fsanitize=address, and as I expected it
  avoids leaking anything, I see only this in the Apache2's error.log:
  ...
  [Sat Apr 19 13:44:58.818704 2014] [core:notice] [pid 18456:tid
  3068020544] AH00094: Command line: '/us
  r/sbin/apache2'
  =
  ==18459==ERROR: AddressSanitizer: heap-buffer-overflow on address
  0xb4960411 at pc 0xb547a785 bp 0xb14f7c88 sp 0xb14f7c7c
  READ of size 1 at 0xb4960411 thread T2
  ASAN:SIGSEGV
  ==18459==AddressSanitizer: while reporting a bug found another
 one.Ignoring.
  =
  ==18461==ERROR: AddressSanitizer: heap-buffer-overflow on address
  0xb4960411 at pc 0xb547a785 bp 0xaf86bc88 sp 0xaf86bc7c
  READ of size 1 at 0xb4960411 thread T5
  ASAN:SIGSEGV
  ==18461==AddressSanitizer: while reporting a bug found another
 one.Ignoring.
  ...
 
  Since this is exactly the flag I looked at for amd64-hardened, if we
  had this arch existing a few weeks ago it would have prevented
  successful attacks on this platform.

 Well this is certainly impressive - I was not aware of AddressSanitizer,
 seems like very powerful and easy to us instrumentation tool.

 AddressSanitizer does not look like a flag intended for hardening. The
 performance slowdown is quite steep. The instrumentation code itself might
 be buggy, causing exploitation potential in itself.

 Essentially this sounds about as wise as running server code under
 valgrind.

  I used Heartleech for triggering the bug and the attached debdiff on
 openssl.
 
  The PoC is fragile because you need to set LD_PRELOAD=libasan1 and
  compile the package with the following command:
  CC=gcc-4.9 DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage -rfakeroot -us -uc
 
  I have also disabled OpenSSL's feelist implementation because any
  custom memory handling would be disabled on amd64-hardened to let ASAN
   work effectively.
 
  During creating the PoC I have hit several bugs which I had to work
  around in the patch:
 
  Changes:
   openssl (1.0.1f-1~dontuseheartbleedtest) UNRELEASED; urgency=low
   .
 * Enable -fsanitize=address
 * Disable freelist using -DOPENSSL_NO_BUF_FREELISTS
 * Add patch to fix freelist reuse from here:
 
 http://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-reuse
 * CVE-2014-0160 a.k.a Heartbleed is not fixed in this version!
 * Add patch 'Check i before r[i]' to fix buffer overflow by reading
 * Export ssl3_write_bytes() for compiling Heartleech
 * Use -DOPENSSL_NO_ASM to prevent crash in OPENSSL_cpuid_setup on i386

 This doesn't really look like a magical if it was just compiled with
 hardening flags, this wouldn't have happened case. The PoC required
 elobarate knowledge where the bug was and how it was hidden by
 openssl's memory allocations. With -DOPENSSL_NO_BUF_FREELISTS the bug
 would have been found with static analysis anyways...

 Riku

Re: Proposing amd64-hardened architecture for Debian

[Bálint Réczey]

Hi Riku,

2014-04-19 13:26 GMT+02:00 Riku Voipio riku.voi...@iki.fi:
 On Tue, Apr 15, 2014 at 12:00:33PM +0200, Balint Reczey wrote:
 Facing last week's Heartbleed [1] bug the need for improving the
 security of our systems became more apparent than usually. In Debian
 there are widely used methods for Hardening [2] packages at build time
 and guidelines [3] for improving the default installations' security.

 Riding the Heartbleed publicity wave seems unwise, unless you can
 propose a hardening flag that would have protected users from
 Heartbleed. Else, Heartbleed merely serves on a example
 how wallpapering problems over with hardened binaries often
 doesn't help you at all..

 Considering that most issues protected by compiler hardening are
 also detectable by static/dynamic code analysis, a more effective security
 measure would be to spend time with clang static analyzer, valgrind, trinity
 and other tools... or actualy reviewing patches that security critical
 projects recieve.
Thank you for bringing this up now.
I have just managed to compile openssl, without the fix for the
Heartbleed test but with -fsanitize=address, and as I expected it
avoids leaking anything, I see only this in the Apache2's error.log:
...
[Sat Apr 19 13:44:58.818704 2014] [core:notice] [pid 18456:tid
3068020544] AH00094: Command line: '/us
r/sbin/apache2'
=
==18459==ERROR: AddressSanitizer: heap-buffer-overflow on address
0xb4960411 at pc 0xb547a785 bp 0xb14f7c88 sp 0xb14f7c7c
READ of size 1 at 0xb4960411 thread T2
ASAN:SIGSEGV
==18459==AddressSanitizer: while reporting a bug found another one.Ignoring.
=
==18461==ERROR: AddressSanitizer: heap-buffer-overflow on address
0xb4960411 at pc 0xb547a785 bp 0xaf86bc88 sp 0xaf86bc7c
READ of size 1 at 0xb4960411 thread T5
ASAN:SIGSEGV
==18461==AddressSanitizer: while reporting a bug found another one.Ignoring.
...

Since this is exactly the flag I looked at for amd64-hardened, if we
had this arch existing a few weeks ago it would have prevented
successful attacks on this platform.

I used Heartleech for triggering the bug and the attached debdiff on openssl.

The PoC is fragile because you need to set LD_PRELOAD=libasan1 and
compile the package with the following command:
CC=gcc-4.9 DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage -rfakeroot -us -uc

I have also disabled OpenSSL's feelist implementation because any
custom memory handling would be disabled on amd64-hardened to let ASAN
 work effectively.

During creating the PoC I have hit several bugs which I had to work
around in the patch:

Changes:
 openssl (1.0.1f-1~dontuseheartbleedtest) UNRELEASED; urgency=low
 .
   * Enable -fsanitize=address
   * Disable freelist using -DOPENSSL_NO_BUF_FREELISTS
   * Add patch to fix freelist reuse from here:
 http://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-reuse
   * CVE-2014-0160 a.k.a Heartbleed is not fixed in this version!
   * Add patch 'Check i before r[i]' to fix buffer overflow by reading
   * Export ssl3_write_bytes() for compiling Heartleech
   * Use -DOPENSSL_NO_ASM to prevent crash in OPENSSL_cpuid_setup on i386


Cheers,
Balint
diff -Nru openssl-1.0.1f/debian/changelog openssl-1.0.1f/debian/changelog
--- openssl-1.0.1f/debian/changelog	2014-01-06 19:02:23.0 +0100
+++ openssl-1.0.1f/debian/changelog	2014-04-18 14:18:09.0 +0200
@@ -1,3 +1,16 @@
+openssl (1.0.1f-1~dontuseheartbleedtest) UNRELEASED; urgency=low
+
+  * Enable -fsanitize=address
+  * Disable freelist using -DOPENSSL_NO_BUF_FREELISTS
+  * Add patch to fix freelist reuse from here:
+http://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-reuse
+  * CVE-2014-0160 a.k.a Heartbleed is not fixed in this version!
+  * Add patch 'Check i before r[i]' to fix buffer overflow by reading
+  * Export ssl3_write_bytes() for compiling Heartleech
+  * Use -DOPENSSL_NO_ASM to prevent crash in OPENSSL_cpuid_setup on i386
+
+ -- Balint Reczey rbal...@minipanda.sz13.dyndns.org  Thu, 17 Apr 2014 20:12:10 +0200
+
 openssl (1.0.1f-1) unstable; urgency=high
 
   * New upstream version
diff -Nru openssl-1.0.1f/debian/patches/0001-Check-i-before-r-i.patch openssl-1.0.1f/debian/patches/0001-Check-i-before-r-i.patch
--- openssl-1.0.1f/debian/patches/0001-Check-i-before-r-i.patch	1970-01-01 01:00:00.0 +0100
+++ openssl-1.0.1f/debian/patches/0001-Check-i-before-r-i.patch	2014-04-17 20:17:12.0 +0200
@@ -0,0 +1,33 @@
+From 73c92dfa0c15d7932d86130a525d1a1bc43c312a Mon Sep 17 00:00:00 2001
+From: Dr. Stephen Henson st...@openssl.org
+Date: Tue, 28 Jan 2014 15:10:27 +
+Subject: [PATCH] Check i before r[i].
+
+PR#3244
+(cherry picked from commit 9614d2c676ffe74ce0c919d9e5c0d622a011cbed)
+---
+ ssl/s3_srvr.c |4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+Index: openssl-1.0.1f/ssl/s3_srvr.c

Re: Proposing amd64-hardened architecture for Debian

[Bálint Réczey]

Hi Martin,

2014-04-16 14:53 GMT+02:00 Martin Wuertele mar...@wuertele.net:
 * Balint Reczey bal...@balintreczey.hu [2014-04-15 12:01]:

 (...)

 My proposal for serving those security-focused users is introducing a
 new architecture targeting amd64 hardware, but with more security
 related C/C++ features turned on for every package (currently hardening
 has to be enabled by the maintainers in some way) through compiler flags
 as a start.

 Introducing the new architecture would also let package maintainers
 enabling additional dependencies and build rules selectively for the new
 architecture improving the security further. On the users' side the
 advantage of having a separate security enhanced architecture instead of
 a Debian derivative is the potential of installing a set of security
 enhanced packages using multiarch [6]. You could have a fast amd64
 installation as a base and run Apache or any other sensitive server from
 the amd64-hardened packages!

 -

 What do you think? Would adding a new arch be feasible and a good solution?

 Why is it not feasable to provide additional -hardened packages? With
 that it would be possible to provide hardened versions of packages on
 other archs as well.
Providing -hardened packages on a per -package basis is certainly
doable, but it would not scale IMO to useful level. With the proposed
multiarch based method one would be pick a binary and all of the
library dependencies from the hardened arch from top to bottom.

In case of providing -hardened binary packages for amd64 to achieve
the same results we would have to wait for all library packagers to
provide -hardened versions and even a single developer not having time
could block the goal.
Managing the dependencies between -hardened and normal libraries seem
to be a complex problem which I would like to avoid.

Cheers,
Balint


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cak0odpytg9u4dkacrebbstk3_a3jjtzvvkmhkwsznnzemjq...@mail.gmail.com

Re: Proposing amd64-hardened architecture for Debian

[Bálint Réczey]

Hi Aaron,

2014-04-16 13:49 GMT+02:00 Aaron Zauner a...@azet.org:
 Hi Balint,

 Balint Reczey wrote:
 Hi,

 I have posted the following idea on my blog [7] to get comments from
 people not on this list, but obviously this is the mailing list where
 the proposal should be discussed. :-)
 I generally agree with your concerns. But I have to concur that
 hardening the default should be the way to go. Besides, this does not
 only concern compiler flags, you'll need kernel hardening and active
 auditing (package source code, userland utitities and so forth). The
 thing is the OpenSSL vulnerability probably wouldn't have been resolved
 using those flags. Another example: stack canaries are a nice idea but
 have since been circumvented as new exploit techniques are constantly
 emerging. Another example: the new Kernel ASLR feature has recently been
 curvumvented by spender of GRSEC. Simply running valgrind on your system
 might flag a lot of false-positives and figuring out what the right
 approach for a given package is will be - again - active auditing and
 thus extremely time consuming. The best way to do this is upstream not
 in a specific distribution from my experience.
I agree that it would be unrealistic to solve all security related
problems with a new architecture, but I think it would be a good way
of improving what we can.

The upstream project I'm most involved in is Wireshark where we try to
employ most of the state of the art techniques for improving code
quality but I think the Wireshark project is in much better position
than most other projects. Thanks to dedicated team and community we
can build on 3 different static analyzers, CI buildbots on 6 different
platforms and tests fuzzing with Valgrind all day long.

For the projects lacking this infrastructure Debian can provide build
tests for many platforms and could also be the project where
additional hardening flags could catch security problems. Expecting
all upstreams to be able to keep up with latest security best
practices is not realistic to me. A trivial example is the case of
dead upstreams.

It is true that stack canaries can't catch everything, but it detects
a fair share of attacks. Note that -fstack-protector is used by
default for all packages in Ubuntu, Fedora, ArchLinux, OpenBSD and
others:
http://en.wikipedia.org/wiki/Buffer_overflow_protection


 A hardened distribution is a lot of effort, I've seen the Gentoo guys
 try it but it seems to be largely unmaintained nowadays. Hence -
 currently - the burden falls on security and systems engineers that
 deploy systems on a given Linux distribution.
The new architecture would target hardening the toolchain as the first
goal and I consider this is doable with reasonable effort. Other parts
like SELinux and Grsecurity-enabled kernel
can be done (and are already being developed) for all architectures
independently from the porting effort.

https://wiki.gentoo.org/wiki/Project:Hardened

Cheers,
Balint


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cak0odpyndqwfd_wu_raqxldgpqebjeg0yeqkc2lrsxp-jbq...@mail.gmail.com

Re: Proposing amd64-hardened architecture for Debian

[Bálint Réczey]

Hi Steve,

2014-04-15 20:07 GMT+02:00 Steve Langasek vor...@debian.org:
 On Wed, Apr 16, 2014 at 12:15:22AM +0800, Thomas Goirand wrote:
  My proposal for serving those security-focused users is introducing a
  new architecture targeting amd64 hardware, but with more security
  related C/C++ features turned on for every package (currently hardening
  has to be enabled by the maintainers in some way) through compiler flags
  as a start.

 My take on this: start it if you wish, and see how it takes you. If it
 is successful enough, it will go to http://www.debian-ports.org/. If it
 has even more success, then probably it will go through the standard
 repository and be official part of Debian. Whatever happens, it will be
 interesting to see what kind of performance hit you get, and what kind
 of security enhancement there is.

 I would not presume that debian-ports.org would be willing to accept this
 port without detailed discussion with Debian about what it means to provide
 a different port with the same ABI.
Thank you for raising this concern. I hope I could get input from
people deciding on accepting/rejecting the proposed port on this list.
If not I'll reach them directly.


 The other recent notable port of this kind (changing the compiler defaults
 without changing the ABI) is Raspbian, which we have not found a way to
 effectively integrate into the Debian archive.  It lives in its own domain,
 not under debian-ports, because it conflicts with and is unidirectionally
 incompatible with the existing armhf port.

 It would be great to see someone tackle the question of subarchs for dpkg,
 which might be a fit here.  But I don't imagine that you're going to get
 signoff on a dpkg amd64-secure architecture, so doing this in debian or on
 debian-ports isn't very practical.
I'm not sure what technical matters prevent having the same ABI in two
different architectures if the multiarch names differ as well, but if
there is any I think they can be handled so I hope to get the signoff.
I would like to avoid going the Raspbian way.

Cheers,
Balint


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAK0OdpzVq_8etn2-KG+HLQ_3=eiqydeu2q0ysgt0h8nvxgq...@mail.gmail.com

Re: Proposing amd64-hardened architecture for Debian

[Bálint Réczey]

2014-04-15 14:23 GMT+02:00 Paul Wise p...@debian.org:
 On Tue, Apr 15, 2014 at 8:15 PM, Christian Hofstaedtler wrote:

 I think that as of today it would help more to fix various upstream
 build tools to actually honor the build flags we (using
 dpkg-buildflags) set. This would benefit both the regular
 architectures and any hypothetical hardened archs.

 Also necessary is for them to support being built with other compilers.
As a package maintainer I make sure that an other compiler and
additional flags are honored whenever it is possible/reasonable by
either patching the build system or upstreaming the patches.
It is worth the effort and is definitely needed, but changing GCC
defaults would speed up making the binaries protected.


 Regarding a special hardened arch, I think on amd64 there's almost
 no benefit of making a seperate arch: just turn on all the hardening
 stuff in amd64, the hardware is fast enough to tolerate some
 slowdown as a tradeoff for better security.
 No ideas for/about the other archs.

 You need a separate architecture if your security enhancements are
 going to give a 50% speed hit.

 https://events.ccc.de/congress/2013/Fahrplan/events/5412.html
 https://media.ccc.de/browse/congress/2013/30C3_-_5412_-_en_-_saal_1_-_201312271830_-_bug_class_genocide_-_andreas_bogk.html
Yes, I fully agree with Paul on this. I was thinking of enabling
address sanitizer in Wireshark (wearing my upstream hat), but the
performance impact (2x slowdown) would be too much for some heavy
users.
http://clang.llvm.org/docs/AddressSanitizer.html

I think it could be enabled in a separate arch.

Cheers,
Balint


 --
 bye,
 pabs

 http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAK0OdpwprpTgAFub=9ogjC=p9ghgjrbaqmny-pbj5mno-ky...@mail.gmail.com

Re: Debian default desktop environment

[Bálint Réczey]

Hi Dmitry,

2014-04-03 23:18 GMT+02:00 Dmitry Smirnov only...@debian.org:
 On Thu, 3 Apr 2014 14:16:15 Undefined User wrote:
 The problem is that right now Debian project is changing its default
 desktop environment, and I think that this is not a good move. Of course,
 it all depends on where the project is aiming at, specially on which users.
 But, for normal users, Gnome 3 is a way better experience than Xfce.

 I think Xfce is much better *default* desktop environment (DE) than Gnome.

 As KDE fan I do not like Gnome. Those who forget to choose DE in installer
 (just like I did more than once) and end up with Xfce will have a lot less to
 remove from their systems shall they choose to use a different DE.

 Faster installation is another good reason to stick with Xfce by default.
Xfce being smaller is a clear technical advantage, but a very weak reason
for choosing it as _the_ single default desktop because this is far
from being only a technical decision.

I myself use awesome WM, but I think Gnome 3 would be the best as a
single default because it is reasonably usable for everyone, it looks
cool and it was the default in Wheezy.

I keep a Gnome 3 installation on  my system to show it to people
interested in learning and converting Linux. I guess you agree that
awesome does not exactly look welcoming. :-)

Xfce is friendly enough, but it feels old compared to Gnome 3 and I
would like to attract new users before convincing them. It is much
easier than in the opposite order. :-)

As a resolution for the lengthy debate I suggest adding a Debian lightweight
desktop environment task to tasksel installing Xfce, providing a
'lightweight desktop' CD #1 shipping it and switching back to Gnome 3
as the default DE.

This would match Ubuntu's offering with Ubuntu/Lubuntu which I found a
proven scheme.

Cheers,
Balint


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cak0odpxnzqizsyn2udotodag0vducnhjb_piydwqwwe4yyr...@mail.gmail.com

Re: contrib and nonfree distribs

[Bálint Réczey]

Hi Solal,

2014-02-28 19:24 GMT+01:00 Solal Rastier solal.rast...@me.com:
 Le 28 févr. 2014 à 19:22, Octavio Alvarez alvar...@alvarezp.ods.org a écrit 
 :

 On 02/28/2014 09:29 AM, Solal Rastier wrote:

 My mail client top-posting automtically. I don't compare Windows and Debian. 
 Windows is proprietariest than Debian, but Debian isn't 100% free. Now, think 
 about the utility of contrib and nonfree. We must create free 
 replacements to proprietary, not put proprietary in Debian.
You are enthusiasm is welcome. Your help in improving free
replacements would also be appreciated.
There are pages for people who would like to start contributing to
Debian, they may be interesting for you:
https://www.debian.org/intro/help
https://wiki.debian.org/how-can-i-help

The more we improve Free Software, the sooner we can remove
non-free(/contrib) parts of Debian.

Cheers,
Balint


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cak0odpxj2e8qtmx8i1fbdjrmezd6y2qufffdgqh-on1xg9j...@mail.gmail.com

Re: [mass bug] New license problem/sourceless fil/privacy problems detected by lintian

[Bálint Réczey]

Hi Bastien,

2014/1/15 Bastien ROUCARIES roucaries.bast...@gmail.com:
 Hi,

 I have just implemented a few new check in lintian:
 detecting non free file based on md5sum[1]. These file are non free.
 I have filled a few bugs and I plan to fill more on it, when I get more 
 reports.
 Please send bug to lintian to add more file to detect. We could also
 detect non distributable file if needed.

 Another tags of interest are detection of flash object [2][3]
 I have filled bug when I could not find the source. I plan to fill more

 Moreover lintian detect minified javascript (based on extension).[4]
 I am slowly manually checking if source is present and fill bug when
 appropriate.
 I plan to detect more minified javascript based on contents analysis
 (line too long some comments) in newer lintian version.

 I have also created tags for .jar and .py(c|o) object but I will not
 open bug and manually check (I am not an expert in these kind of
 stuff). Please java team and python get a glimpse at these tags [5][6]

 Last but not least I have splitted the privacy-breach tags. Lintian
 gives now some piece of advice depending of the problem.

 Feel free to open bugs against lintian in case of false positive or
 other problems [7]

 Thank you

 [1] http://lintian.debian.org/tags/license-problem-md5sum-non-free-file.html
 [2] http://lintian.debian.org/tags/source-contains-prebuilt-flash-object.html
 [3] http://lintian.debian.org/tags/source-contains-prebuilt-flash-project.html
 [4] 
 http://lintian.debian.org/tags/source-contains-prebuilt-javascript-object.html
 [5] http://lintian.debian.org/tags/source-contains-prebuilt-java-object.html
 [6] http://lintian.debian.org/tags/source-contains-prebuilt-python-object.html
 [7] Please read first about privacy-breach-logo
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=735321#10


Thank you for implementing the lintian checks and notifying maintainers
through bug reports.
I'm about to fix the one created against xbmc because I already planned
removing some other embedded but unused libraries anyway, but I would
like to suggest using the important severity as a start for such bugs.
Later the severity could be upgraded if there is no action on the maintainer's
side.

The rationale behind this proposal is that considering xbmc, source creates
a new 24MB source package and ~30MB of binary packages per architecture.
I expect more similar checks to be implemented and more bugs to be
opened against many packages.
Opening the bugs as important, thus not RC ones would allow maintainers
to collect more fixes to fewer package updates not having to worry about
automated removal of their packages from testing.

I agree that the detected issues are RC, and I also agree with the current
autoremoval procedure but IMO having more time to fix these issues
would allow using the project's resources and maintainters' time better.

Cheers,
Balint


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAK0OdpxETE1U11zEQu6sBfxXhmygYT9GYpu4a+NvzkRsMHo=u...@mail.gmail.com

Re: XBMC packaging (was: Re: Bug#732159: Should this package be removed?)

[Bálint Réczey]

Hi Andreas,

2013/12/23 Andreas Tille andr...@an3as.eu:
 Hi Balint,

 On Sun, Dec 22, 2013 at 08:39:17PM +0100, Balint Reczey wrote:
 Thank you for the invitation. I don't know the full story behind XBMC
 and the Multimedia Team, thus I would like to start maintaining it
 outside of the team, then when both upstream and the team is satisfied
 with XBMC's state in Debian I would happily join.

 You are free to do your voluntary work the way you like it but as some
 kind advise I would like to tell you that doing things in teams is often
 fruitful and you are somehow refusing the help of others if you follow
 this strategy.
I would have happily accepted the offer immediately and would have joined
the team if upstream had not been very skeptical about maintaining XBMC
in Debian at all [1].
I made promises regarding the way of maintaining the package and I think
it would look bad if right when starting th maintenance I put it under
the umbrella of Multimedia Team and bring a team of additional maintainers
aboard.
I have just subscribed to the Multimedia mailing lists and I'll post
my introduction
to join the team. I just would like to join with XBMC later, after I
discussed it with
upstream in advance and they (and Multimedia Team, too) are happy about it.

Cheers,
Balint

[2] http://forum.xbmc.org/showthread.php?tid=177474page=1


 I have created a git repository [1] under collab-maint for now. It still
 does not conform fully to Multimedia policy, but I tried to start the
 convergence. :-)

 OK

 Kind regards

Andreas.

 --
 http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cak0odpxp6jsxxctuh6k+fq4kksgvpxtf0l-y5-qkgoc6urq...@mail.gmail.com

Re: XBMC packaging (was: Re: Bug#732159: Should this package be removed?)

[Bálint Réczey]

2013/12/23 Jonas Smedegaard d...@jones.dk:
 Quoting Bálint Réczey (2013-12-23 12:21:28)
 2013/12/23 Andreas Tille andr...@an3as.eu:
 On Sun, Dec 22, 2013 at 08:39:17PM +0100, Balint Reczey wrote:
 Thank you for the invitation. I don't know the full story behind
 XBMC and the Multimedia Team, thus I would like to start
 maintaining it outside of the team, then when both upstream and the
 team is satisfied with XBMC's state in Debian I would happily join.

 You are free to do your voluntary work the way you like it but as
 some kind advise I would like to tell you that doing things in teams
 is often fruitful and you are somehow refusing the help of others if
 you follow this strategy.
 I would have happily accepted the offer immediately and would have
 joined the team if upstream had not been very skeptical about
 maintaining XBMC in Debian at all [1].

 I made promises regarding the way of maintaining the package and I
 think it would look bad if right when starting th maintenance I put it
 under the umbrella of Multimedia Team and bring a team of additional
 maintainers aboard.
 I have just subscribed to the Multimedia mailing lists and I'll post
 my introduction
 to join the team. I just would like to join with XBMC later, after I
 discussed it with
 upstream in advance and they (and Multimedia Team, too) are happy
 about it.

 Cheers,
 Balint

 [2] http://forum.xbmc.org/showthread.php?tid=177474page=1

 Your approach and dialogue upstream looks quite good to me!
Thank you!
I have uploaded 2:12.2+dfsg1-1 and wrote a blog article [3] to explain
the changes.
So far the package looks OK, but there is a lot of room for improvements.
Patches (and other forms of help) are always welcome! :-)

Cheers,
Balint

[3] http://balintreczey.hu/blog/introducing-xbmc-from-debian/


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAK0OdpysVyQSAGz-XmX3u=Npjmada9zc8=pazdnd3steisq...@mail.gmail.com

Re: Bug#732159: Should this package be removed?

[Bálint Réczey]

Hi Reinhard,

2013/12/16 Reinhard Tartler siret...@gmail.com:
 On Sun, Dec 15, 2013 at 5:27 PM, Bálint Réczey bal...@balintreczey.hu wrote:

 Regarding xbmc please don't remove it.
 It works with libav to some extent and I'm tyring to convince upstream to
 let me join the team responsible for packaging. I plan keeping xbmc working
 with libav unless ffmpeg gets reintroduced to the archive.

 Thanks for working on xbmc. BTW, Are you in touch with Andres about that?
I tried to reach him and team-x...@lists.launchpad.net several times
without success.
Now the MIA Team is tracking him, too.
Unfortunately it takes ~10 weeks to have his packages orphaned and then I can
adopt and update xbmc and libcec (a dependency of xbmc).


 In any case, please do file bugs, preferably upstream, for any
 functionality that xbmc requires but is lacking in libav.
I'll do so.

Cheers,
Balint


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cak0odpy9n-uduzdqkkmw6z6wotqsrdwxzhozz_wpxnxktaz...@mail.gmail.com

Re: Bug#732159: Should this package be removed?

[Bálint Réczey]

2013/12/16 Mathieu Malaterre ma...@debian.org:
 On Mon, Dec 16, 2013 at 11:01 AM, Bálint Réczey bal...@balintreczey.hu 
 wrote:
 Hi Reinhard,

 2013/12/16 Reinhard Tartler siret...@gmail.com:
 On Sun, Dec 15, 2013 at 5:27 PM, Bálint Réczey bal...@balintreczey.hu 
 wrote:

 Regarding xbmc please don't remove it.
 It works with libav to some extent and I'm tyring to convince upstream to
 let me join the team responsible for packaging. I plan keeping xbmc working
 with libav unless ffmpeg gets reintroduced to the archive.

 Thanks for working on xbmc. BTW, Are you in touch with Andres about that?
 I tried to reach him and team-x...@lists.launchpad.net several times
 without success.
 Now the MIA Team is tracking him, too.
 Unfortunately it takes ~10 weeks to have his packages orphaned and then I can
 adopt and update xbmc and libcec (a dependency of xbmc).

 Are you part of XBMC-Team ? If so simply list yourself in the Uploaders field.
No, I tried to reach them several times, but none of the _Launchpad_
team members replied.
I'm working [1] with the upstream developers and when they are OK with
the package I plan
uploading it.

 If you upload your package on -say- mentors.d.n, I can review and
 upload as a team upload[*] (or NMU if needed).
Thank you for the offer, but I'm a DD thus I can perform uploads directly.

Cheers,
Balint


 Thanks for working on xbmc !
 [*] See dch --team

[1] http://forum.xbmc.org/showthread.php?tid=177474page=1


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cak0odpwe6etuqrbedwn43p52kfex3qrrdz2fomdxmr_2h1f...@mail.gmail.com

Re: Bug#732159: Should this package be removed?

[Bálint Réczey]

2013/12/15 Reimar Döffinger reimar.doeffin...@gmx.de:
 On 14.12.2013, at 23:53, John Paul Adrian Glaubitz 
 glaub...@physik.fu-berlin.de wrote:
 On 12/14/2013 11:07 PM, Reinhard Tartler wrote:
 On Sat, Dec 14, 2013 at 4:28 PM, Moritz Muehlenhoff j...@debian.org wrote:
 Package: mplayer
 Severity: serious

 Should this package be removed? If so, please reassign to ftp.debian.org

 - Last upload nearly two years ago
 - FTBFS for a long time
 - Incompatible with current libav
 - Alternatives exist (mplayer2, mpv)

 Well, to be honest, I think the problem is actually libav, not mplayer.
 Most users prefer the original ffmpeg over libav from my own experience.

 And there are new upstream releases of mplayer which are actually more
 frequent and active than mplayer2:

 - mplayer: current stable release 1.1.1, released May 6th, 2013
 - mplayer2: current stable release 2.0, released: March 24th, 2011

 Even the latest git commit for mplayer2 is older than the current
 stable release of mplayer. The latter seems much more active to me.

 So, what I'd rather like to see is that we get a proper ffmpeg
 back in Debian again which would also allow to update mplayer
 to the current upstream version. There is even an RFP for
 that [1]. But I guess this is not going to happen.

 I'm still a bit sad that the split among the ffmpeg people
 happened.

 Adrian

 [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729203

 I thought someone was working on it already, but I am happy to help out both 
 with getting a parallel install of FFmpeg working (via a rpath hack for 
 example, supported in FFmpeg configure but probably needs fixes to MPlayer's 
 configure to work) and to a limited degree also making MPlayer work with 
 Libav.
How about introducing the ffmpeg shared libraries with libffmpeg
prefix instead of libav prefix?
This would rename the libraries, but since none of the forks shows
interest in using different library names and users already refer to
ffmpeg or libav versions it would cause just a little confusion.
This way the libraries could coexist on the same system and we could
avoid using the rpath hack.

Cheers,
Balint

PS: I'm interested in the topic because I'm working on reviving the
XBMC package but upstream prefers ffmpeg over libav.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cak0odpyn3sun-8ac9dx_owplni9u8-a4nknv+6dozbteyt4...@mail.gmail.com

Re: Bug#732159: Should this package be removed?

[Bálint Réczey]

2013/12/15 John Paul Adrian Glaubitz glaub...@physik.fu-berlin.de:
 On 12/15/2013 10:11 PM, Moritz Mühlenhoff wrote:
 Bálint Réczey bal...@balintreczey.hu schrieb:
 How about introducing the ffmpeg shared libraries with libffmpeg
 prefix instead of libav prefix?

 No way. Keeping up with security fixes for libav is tedious enough,
 we cannot reasonably have both.

 So, the alternatives then are either removing xbmc, mplayer and all
 packages with dependencies on these or switching back to ffmpeg?
Regarding xbmc please don't remove it.
It works with libav to some extent and I'm tyring to convince upstream to
let me join the team responsible for packaging. I plan keeping xbmc working
with libav unless ffmpeg gets reintroduced to the archive.

I understand Moritz's concerns regarding the security fixes and I'm not taking
sides whether ffmpeg should be reintroduced, but if it gets reintroduced without
removing libav, please avoid the rpath hack and use different .so names instead.

Cheers,
Balint


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cak0odpxqmvnnippbpcuscxedbop8jktiw4w0ducp_quosrx...@mail.gmail.com

Re: Berkeley DB 6.0 license change to AGPLv3

[Bálint Réczey]

2013/7/4 Ondřej Surý ond...@sury.org:

 On Thu, Jul 4, 2013 at 6:51 PM, Bradley M. Kuhn bk...@ebb.org wrote:

  2) We need to pick the Berkeley DB version compatible with all
  packages that use the library.

 I think this is roughly the same issue as (1), unless you mean a
 technical rather than a licensing issue.


 It is a more technical issue, but based on licensing issue. We need to pick
 BDB version with license which is compatible with all packages that uses it.
Strictly regarding the technical problem I think Ben's suggestion would work:
2013/7/2 Ben Hutchings b...@decadent.org.uk:
 On Tue, 2013-07-02 at 09:35 -0400, Paul Tagliamonte wrote:
 On Tue, Jul 02, 2013 at 09:15:15AM -0400, Paul Tagliamonte wrote:
  Again, why do you plan on removing free software from main due to a
  change in license?

 As algernon points out, it makes slightly more sense when you remember
 that the AGPLv3 is not compatable with the GPLv2

 I'm still against removing it from the archive.

 But the new version should not build the default libdb-dev, as that is
 likely to result in unintended GPLv2/v3 combinations that cannot be
 distributed.

We could keep libdb-dev for the fork keeping the current license and
create a new set of
development packages like libdb6-dev for the AGPLv3 code with or
without switching to an
upstream different from Oracle.

Packages depending on more liberally licensed Berkeley DB won't switch
automatically to
the AGPLv3 this way.

Cheers,
Balint


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cak0odpxntt9luw+ys8s09zd2iv5p33vy_boexdaa3svfin+...@mail.gmail.com

Re: DM upload permission

[Bálint Réczey]

Hi,

2013/3/5 Arno Töll a...@debian.org:
 Ho Carlo,

 On 05.03.2013 07:42, Carlo Segre wrote:
 1. made a file called segre-0001.dak-commands with the following contents

 Action: dm
 Fingerprint: 8CCC1BA8590FF029D17C708FC1BCD3C72AA28B6B
 Allow: nexus


 You missed the header. While the Uploader field is optional (and also
 used for the mail confirmation you're missing by the way), the Archive
 field is not. Moreover, the blank newline dividing the header from the
 data part is required.

 That is, your command would be:

 ---
 Archive: ftp.debian.org
 Uploader: Carlo Segre se...@iit.edu

 Action: dm
 Fingerprint: 8CCC1BA8590FF029D17C708FC1BCD3C72AA28B6B
 Allow: nexus
 ---

 Note, you can also use dput-ng (available in unstable) to manage DM
 permissions. The equivalent command would be:

 dcut dm --uid Tobias Stefan Richter --allow nexus


Please send error reports to the affected parties when executing or
parsing a dak command file fails.

Also please send emails when a DM without proper upload rights set
uploads a package and it is dropped.
Yes, it happened to me and the wireshark package got stuck in the
upload queue for a few hours and then it got
dropped without any email sent to me about the reason.

Thanks,
Balint


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAK0Odpyv-ntOnwT=2mum5itxrhbycfxs3yeenongxhc8piq...@mail.gmail.com

Re: Bug#690544: ITP: xts -- GNU R package for time series analysis

[Bálint Réczey]

2012/10/15 Julien Cristau jcris...@debian.org:
 On Mon, Oct 15, 2012 at 20:13:33 +0800, Lifeng Sun wrote:

 Package: wnpp
 Severity: wishlist
 Owner: Lifeng Sun lifong...@gmail.com
 X-Debbugs-Cc: debian-devel@lists.debian.org, debian-scie...@lists.debian.org

 * Package name: xts
   Version : 0.8-6
   Upstream Author : Jeffrey A. Ryan jeff.a.r...@gmail.com
 Josh M. Ulrich
 * URL : http://r-forge.r-project.org/projects/xts/
 * License : GPL-2
   Description : GNU R package for time series analysis -- xts

 This package provide uniform handling of R's different time-based data
 classes by extending r-cran-zoo, maximizing native format information
 preservation and allowing for user level customization and extension,
 while simplifying cross-class interoperability.

 Any chance you could choose a better package name?  Something that hints
 at this being related to R.  xts to me is the X Test Suite, which has
 nothing to do with this.

 Thanks,
 Julien

Hi,

r-cran-xts would fit existing naming scheme nicely.
The same scheme could be used for performanceanalytics as well.

Cheers,
Balint


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAK0OdpzroVoBLM=qdmmkpsj-ufqj84upmp0omewmaxsxmke...@mail.gmail.com

Re: Wheezy release: CDs are not big enough any more...

[Bálint Réczey]

Hi,

2012/5/14, Marco d'Itri m...@linux.it:
 On May 14, Adam Borowski kilob...@angband.pl wrote:

 Ie, the problem is not in d-i, but in running debootstrap on foreign
 systems.  And that's indeed not easily fixable :(
 Do we actually have an official debootstrap package for foreign systems?
 We could ship a static busybox with it and solve this and other issues.
 (I know, not all the world is a VAX, etc... But we cannot solve *every*
 problem.)

 If the problem is foreign systems without xz then we will never be
 able to use XZ for base.
How about switching to xz in the standard installer and providing an
alternate installer with recompressed packages using gzip/bz2?

This would allow us to support most systems and save on bandwidth/mirror space.

Cheers,
Balint


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cak0odpz22hykynctp+3vp10oj0q8r5p_tr2s+gofz12zqcm...@mail.gmail.com

Re: The archive now supports xz compression

[Bálint Réczey]

Hi,
2011/8/15 Eduard Bloch e...@gmx.de:
 #include hallo.h
 * Roger Leigh [Sun, Aug 14 2011, 11:01:11PM]:
 On Sun, Aug 14, 2011 at 09:19:02PM +0200, Lucas Nussbaum wrote:
  On 11/08/11 at 19:52 +, Philipp Kern wrote:

  Wouldn't it be better to get more buildds for those archs, then?
  That would be a totally appropriate use of Debian money...

 Possibly a stupid question here but: Given that we are now autosigning
 builds, why can't the slower arches use gzip, and then after upload
 they could be recompressed with xz (and resigned) on a faster arch?
 This would allow xz compression on all arches, but not require slow
 arches to actually do the xz compression themselves.

 Yeah, but if we got that far then we could easily create a remote
 compressing service for such systems. Can be easily achieved by
 configuring xz as service in inetd.conf and hacking dpkg-dev to run
 something like socket -q localRocketFastSystem instead of xz on the
 build machine.
Maybe we don't have to hack dpkg-dev. Maybe could replace xz with
netcat on slow build machines.

Cheers,
Balint


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cak0odpwvrqkcvzfvys0sspnxqsiuu-kzrz5kjztoutoydaw...@mail.gmail.com