I plan to add support for 'XB-Popcon-Reports: no' to
popularity-contest.
This allows to build packages with private names that will not be
reported to popcon, by adding 'XB-Popcon-Reports: no' to
debian/control.
This must not used by packages in the debian archive, however that can
be used by packages generators that create packages with randomly
generated names (package names that include 128bit uuid for examples)
or by organizations that generates packages for internal use
whose name include the organization name.
The rationale is that the only info really leaked is the package name,
so it only make sense to hide a package if every system that have it installed are also hiding it, so it is better to make it a property
of the package than of the system.
Bill Allombert <ballombe@debian.org> writes:
I plan to add support for 'XB-Popcon-Reports: no' to popularity-
contest.
This allows to build packages with private names that will not be
reported to popcon, by adding 'XB-Popcon-Reports: no' to
debian/control.
This must not used by packages in the debian archive, however that
can
be used by packages generators that create packages with randomly
generated names (package names that include 128bit uuid for
examples) or
by organizations that generates packages for internal use whose
name
include the organization name.
The rationale is that the only info really leaked is the package
name,
so it only make sense to hide a package if every system that have
it
installed are also hiding it, so it is better to make it a property
of
the package than of the system.
Any comment ?
This sounds like a good idea to me.
Using an additional binary package control field felt weird to me,
and I wanted to believe there was some better place to put this
information rather than introducing yet another boolean control
field, but after thinking about it for a bit, I couldn't think of any
better place that made much sense.
I plan to add support for 'XB-Popcon-Reports: no' to popularity-contest.
This allows to build packages with private names that will not be
reported to popcon, by adding 'XB-Popcon-Reports: no' to debian/control.
This must not used by packages in the debian archive, however that can
be used by packages generators that create packages with randomly
generated names (package names that include 128bit uuid for examples) or
by organizations that generates packages for internal use whose name
include the organization name.
The rationale is that the only info really leaked is the package name,
so it only make sense to hide a package if every system that have it installed are also hiding it, so it is better to make it a property of
the package than of the system.
Any comment ?
I like the idea, especially for organizations who know what they are doing[1]. I just fear that it won't actually solve your denylisting
problem at hand. People will keep not specifying it. Can't popcon go and
just accept reports for packages in the archive somehow?
I don't know if it currently does this, but it would be useful for popcon
to show counts for public third-party packages that aren't in the archive.
The rationale is that the only info really leaked is the package name,
so it only make sense to hide a package if every system that have it installed are also hiding it, so it is better to make it a property
of the package than of the system.
]] Bill Allombert
The rationale is that the only info really leaked is the package name,
so it only make sense to hide a package if every system that have it installed are also hiding it, so it is better to make it a property
of the package than of the system.
I think it'd make more sense for this to be an opt-in property of the
source of the package, that is, based on which archive it's coming
from.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (1 / 15) |
| Uptime: | 160:36:52 |
| Calls: | 10,385 |
| Calls today: | 2 |
| Files: | 14,056 |
| Messages: | 6,416,493 |