Re: popularity-contest: support for XB-Popcon-Reports: no

[Bill Allombert]

On Thu, May 05, 2022 at 07:15:06AM +0200, Tollef Fog Heen wrote:
> ]] 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.

Manually generated packages are usually installed with 'dpkg -i' and 
do not come from an archive.  If the package in available on a public
archive, its name is public by definition.
Also, it is very hard to associate installed packages to archives.
source.lists might even have been changed after the package was installed.

Cheers,
-- 
Bill. 

Imagine a large red swirl here.

Re: rules-needs-root: yes (Was: popularity-contest: support for XB-Popcon-Reports: no)

[Andrey Rahmatullin]

On Thu, May 05, 2022 at 11:31:37AM +0200, Andreas Tille wrote:
> > If there's a growing list of boolean control fields, isn't it the
> > indication that some sort of tagging system might make more sense?
> > 
> > Instead of three lines:
> > 
> > XB-Popcon-Reports: no
> > Rules-Requires-Root: yes
> > Pants-Need-Washing: yes
> > 
> > The same package could use a single line:
> > 
> > Tags: no-popcon-reports, rules-needs-root, pants-need-washing
> 
> ACK.
>  
> > (aside: by default rules doesn't need root... that would make one not-
> > very-useful line less in so many packages!)
> 
> I'd like to stress this!  If "rules-needs-root: no" would be default
> the majority of packages could be build.  So why not making this the
> default and just specify
>rules-needs-root: yes
> if needed?
First, strictly speaking it's not boolean, at least until #975637 is
implemented.
Second, changing the default is a breaking change. Is there any statistics
how many of the packages not already having a Rules-Requires-Root field
(which are a half of them according to trends.d.n) are working fine with
Rules-Requires-Root: no? 
Also note that "yes" doesn't exist, the correct value for the current
default is "binary-targets".

-- 
WBR, wRAR


signature.asc
Description: PGP signature

rules-needs-root: yes (Was: popularity-contest: support for XB-Popcon-Reports: no)

[Andreas Tille]

Hi,

Am Wed, May 04, 2022 at 07:23:43PM +0200 schrieb julien.pu...@gmail.com:
> If there's a growing list of boolean control fields, isn't it the
> indication that some sort of tagging system might make more sense?
> 
> Instead of three lines:
> 
> XB-Popcon-Reports: no
> Rules-Requires-Root: yes
> Pants-Need-Washing: yes
> 
> The same package could use a single line:
> 
> Tags: no-popcon-reports, rules-needs-root, pants-need-washing

ACK.
 
> (aside: by default rules doesn't need root... that would make one not-
> very-useful line less in so many packages!)

I'd like to stress this!  If "rules-needs-root: no" would be default
the majority of packages could be build.  So why not making this the
default and just specify
   rules-needs-root: yes
if needed?

> Some of our tools might provide easy queries to the feature:
> 
> $ apt-cache has-tag rules-needs-root my-beautiful-package
> 
> $ apt-cache list-tags my-beautiful-package

Makes sense.

Kind regards
   Andreas. 

-- 
http://fam-tille.de

Re: popularity-contest: support for XB-Popcon-Reports: no

[Tollef Fog Heen]

]] 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.

(Strawmen: Put a field in Release saying «please send in popcon
reports», have popcon enumerate the configured apt sources and check
that the version number of installed packages match what exist in those
sources, or have a passlist in the «receive report» stage on the server
that looks at which distribution is being reported for and validate that
those packages (and possibly versions) exist or have existed in the
past.)

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Re: popularity-contest: support for XB-Popcon-Reports: no

[Peter]

On 04/05/2022 19:43, Russ Allbery wrote:


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.


See
https://popcon.debian.org/unknown/by_recent


Cheers,
Peter

Re: popularity-contest: support for XB-Popcon-Reports: no

[Russ Allbery]

Philipp Kern  writes:

> 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.
Counts for things like google-chrome or non-archive Kubernetes packages
provide possibly useful information about how our users use the
distribution, and they've opted into sharing that information with us.

That said, I'm not sure that anyone uses that information right now, which
may make this a weak argument.

-- 
Russ Allbery (r...@debian.org)  

Re: popularity-contest: support for XB-Popcon-Reports: no

[Philipp Kern]

Hi,

On 2022-05-04 18:21, Bill Allombert wrote:
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.


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?


Kind regards
Philipp Kern

[1] Although most might disable popcon anyway.

Re: popularity-contest: support for XB-Popcon-Reports: no

[julien . puydt]

Le mercredi 04 mai 2022 à 10:12 -0700, Russ Allbery a écrit :
> Bill Allombert  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.
> 

I do see the need.

> 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.

If there's a growing list of boolean control fields, isn't it the
indication that some sort of tagging system might make more sense?

Instead of three lines:

XB-Popcon-Reports: no
Rules-Requires-Root: yes
Pants-Need-Washing: yes

The same package could use a single line:

Tags: no-popcon-reports, rules-needs-root, pants-need-washing

(aside: by default rules doesn't need root... that would make one not-
very-useful line less in so many packages!)

Some of our tools might provide easy queries to the feature:

$ apt-cache has-tag rules-needs-root my-beautiful-package

$ apt-cache list-tags my-beautiful-package

Cheers,

J.Puydt

Re: popularity-contest: support for XB-Popcon-Reports: no

[Russ Allbery]

Bill Allombert  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.

-- 
Russ Allbery (r...@debian.org)  

popularity-contest: support for XB-Popcon-Reports: no

[Bill Allombert]

Dear Debian developers,

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 ?

Cheers,
-- 
Bill. 

Imagine a large red swirl here.