Opened 20 months ago

Last modified 15 months ago

#26848 closed task

Create Debian package for sbws — at Version 10

Reported by: juga Owned by: juga
Priority: Medium Milestone: sbws: 1.0.x-final
Component: Core Tor/sbws Version:
Severity: Normal Keywords: sbws-1.0-must-closed-moved-20181128
Cc: pastly, juga, teor, stefani@…, arma, mail@…, micah@…, adejoode@… Actual Points:
Parent ID: #25925 Points:
Reviewer: Sponsor:

Description (last modified by juga)

We agreed that to easy bandwidth authorities to run sbws we should have a Debian package.
This is also part of #17275.
This ticket follows the issue created in github [0]

Tasks to have a Debian package:

  • [x] create a proper Python package (solved by GHXX, GHXX, GHXX)
  • [x] create metadata for the Python package, useful for source and binary distributions (solved by GHXX)
  • [X] create Debian ITP [1] (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903976)
  • [X] try to get a team to collectively maintain the package so that it does not depend on a single person (https://alioth-lists.debian.net/pipermail/pkg-privacy-maintainers/Week-of-Mon-20180716/002184.html)
  • [ ] get steam to release new version, currently blocked by #26412
  • [ ] (optionall) provide sbws releases via dist.tpo (#26849) so that watch does not use Github
  • [ ] create debian source package in Debian repositories (salsa.debian.org)
  • [ ] get the source reviewed
  • [ ] get the package uploaded to Debian archive (sid)
  • [ ] create debian backport to current stable (stretch)
  • [ ] get backport reviewed
  • [ ] get backport uploaded to Debian archive
  • [ ] (optional) upload the package to deb.tpo
  • [ ] (optional) create bug in Ubuntu to get the package distributed in Ubuntu too

[0] https://github.com/pastly/simple-bw-scanner/issues/101
[1] https://wiki.debian.org/ITP

Edit:

  • link to ITP bug, mark as done
  • [ ] get ITP accepted
  • [ ] (optionall) provide sbws releases via dist.tpo (#XXX) so that watch does not use Github
  • [ ] get the source reviewed
  • [ ] get the package uploaded to Debian archive (sid)
  • [ ] create debian backport to current stable (stretch)
  • [ ] get backport reviewed
  • [ ] get backport uploaded to Debian archive
  • [ ] (optional) upload the package to deb.tpo
  • [ ] (optional) create bug in Ubuntu to get the package distributed in Ubuntu too
  • Add ticket number for having releases in dist.tpo
  • Add link to team mail

Child Tickets

TicketStatusOwnerSummaryComponent
#26849closedUpload sbws releases in dist.torproject.orgInternal Services/Service - dist
#26862closedjugasbws should allow a configuration file argumentCore Tor/sbws
#26926closedjugaBinaries should have manual pages (man)Core Tor/sbws

Change History (10)

comment:1 Changed 20 months ago by juga

Description: modified (diff)

comment:2 Changed 20 months ago by juga

Description: modified (diff)

comment:3 Changed 20 months ago by juga

Description: modified (diff)

comment:4 Changed 20 months ago by teor

Instead of modifying the description, you can open child tickets, and close them when they're done.
Then the "child tickets" table in this ticket will automatically show their statuses.

comment:5 Changed 20 months ago by irl

I'm *really* not convinced it is a good idea to do this.

Creating the structure of a Debian package and building a policy-compliant package is a great idea and would make deployment easier, as long the the dirauths are running Debian which at least dannenberg and maatuska are not.

My main objection to this though is that the package is not really useful outside of the directory authorities, not all of which run Debian and not all of which might even run sbws. It could be though that many people decide they want to measure the network themselves just for fun, and generate useless load.

(optionall) provide sbws releases via dist.tpo (#26849) so that watch does not use Github

You could just do this anyway, and have the dirauths fetch the code from here? This would work for all platforms then.

Assuming that you do go ahead with this anyway and there's something I'm missing:

get ITP accepted

I have no idea what this means. If you file an ITP bug it means you intend to package it. No one accepts or rejects these although discussion may happen on the bug.

create debian backport to current stable (stretch)

Note that it would take 10 days after the upload to unstable is accepted (sometimes more) to be able to upload a backport. If the dirauths are running stable, they would be delayed 10 days upgrading while this happens.

(optional) create bug in Ubuntu to get the package distributed in Ubuntu too

If it's in unstable you'll find it just appears in Ubuntu. It's not, in my experience, that quick to get updates to go in. This will be especially apparent with such a niche package.

comment:6 Changed 20 months ago by dkg

irl, i can't tell if you're "really not convinced it's a good idea" or if you're "really convinced it's not a good idea". :)

having a debian package can help for identifying problems, for system integration, and for ease of updates.

If there's a real concern about people measuring the network who shouldn't be, then i'm not sure that the presence of software in the debian repository or not is going to stop any even mildly interested actor. If you want to ensure that only "the right" people run sbws, you could have the dedicated debian system service do some sort of verification that it is on a host that is "acceptable", and then decline to run unless the administrator overrides it, but that seems like a lot of work to put in to an antifeature in free software.

as for the cadence of uploads to stable-backports -- packages with a passing [DEP-8 autopkgtest testsuite](https://dep-team.pages.debian.net/deps/dep8/) and no outstanding RC bugs can [migrate from unstable to testing in less time](https://lists.debian.org/debian-devel-announce/2018/05/msg00001.html), which allows for an upload to stretch-backports faster. It also means that we can rely on debian's testing infrastructure to verify basic package functionality on minimal systems. taking advantage of that continuous integration infrastructure seems like a good idea regardless of the package migration times.

what cadence do we expect bandwidth measurement upgrades to take anyway? do current measurement sites deploy them in hours instead of days today?

comment:7 in reply to:  5 ; Changed 20 months ago by juga

Replying to irl:

I'm *really* not convinced it is a good idea to do this.

i'm not totally convinced either, but asked around for some time and we decided to go for it.

Creating the structure of a Debian package and building a policy-compliant
package is a great idea and would make deployment easier, as long the the
dirauths are running Debian which at least dannenberg and maatuska are
not.

the majority are running Debian.

My main objection to this though is that the package is not really useful
outside of the directory authorities, not all of which run Debian and not
all of which might even run sbws. It could be though that many people
decide they want to measure the network themselves just for fun, and
generate useless load.

i share this concern seems months when i first thought to do this. But:

  1. in theory anyone could have been running torflow (just a bit harder

to install) for 6 years

  1. in theory anyone can run sbws now (not hard to install)
  2. some dirauths would refuse to install something from

unsafe/unverified sources

(optionall) provide sbws releases via dist.tpo (#26849) so that watch

does not use Github

You could just do this anyway, and have the dirauths fetch the code from
here? This would work for all platforms then.

agree, the ticket is created. Still upstream releases would miss
important system configuration/dependencies.

Assuming that you do go ahead with this anyway and there's something I'm
missing:

get ITP accepted

I have no idea what this means. If you file an ITP bug it means you intend
to package it. No one accepts or rejects these although discussion may
happen on the bug.

New packages need to close an ITP. AFAICT that discussion is important
to actually decided whether it makes sense to have the package in Debian.

create debian backport to current stable (stretch)

Note that it would take 10 days after the upload to unstable is accepted
(sometimes more) to be able to upload a backport. If the dirauths are
running stable, they would be delayed 10 days upgrading while this
happens.

security updates for backports happen faster?

(optional) create bug in Ubuntu to get the package distributed in Ubuntu

too

If it's in unstable you'll find it just appears in Ubuntu.

didn't know this.

It's not, in my

experience, that quick to get updates to go in. This will be especially
apparent with such a niche package.

Note there's also:

[ ] (optional) upload the package to deb.tpo

Alternatively we could upload it only there, but arma mentioned that only packages that are also in Debian archive go there, cause otherwise would end up unmaintained.

comment:8 in reply to:  7 ; Changed 20 months ago by irl

Replying to dkg:

irl, i can't tell if you're "really not convinced it's a good idea" or if you're "really convinced it's not a good idea". :)

I'm not sure yet.

having a debian package can help for identifying problems, for system integration, and for ease of updates.

Not all are Debian though. We should be identifying problems with good test suites.

If there's a real concern about people measuring the network who shouldn't be, then i'm not sure that the presence of software in the debian repository or not is going to stop any even mildly interested actor. If you want to ensure that only "the right" people run sbws, you could have the dedicated debian system service do some sort of verification that it is on a host that is "acceptable", and then decline to run unless the administrator overrides it, but that seems like a lot of work to put in to an antifeature in free software.

I'm thinking of people installing it by accident. Relay operators that are looking for nyx may see "Tor Bandwidth Scanner" and think that is what they're looking for.

as for the cadence of uploads to stable-backports -- packages with a passing [DEP-8 autopkgtest testsuite](https://dep-team.pages.debian.net/deps/dep8/) and no outstanding RC bugs can [migrate from unstable to testing in less time](https://lists.debian.org/debian-devel-announce/2018/05/msg00001.html), which allows for an upload to stretch-backports faster. It also means that we can rely on debian's testing infrastructure to verify basic package functionality on minimal systems. taking advantage of that continuous integration infrastructure seems like a good idea regardless of the package migration times.

Ah ok, that's a new thing I did not know about. (: I'll withdraw that objection.

Replying to juga:

Creating the structure of a Debian package and building a policy-compliant
package is a great idea and would make deployment easier, as long the the
dirauths are running Debian which at least dannenberg and maatuska are
not.

the majority are running Debian.

Do we plan to mandate that dirauths run Debian if they are to have bandwidth scanners?

i share this concern seems months when i first thought to do this. But:

  1. in theory anyone could have been running torflow (just a bit harder

to install) for 6 years

I'm not thinking so much about people running it maliciously, but accidentally and then forgetting about it. This could become a cumulative problem over time.

You could just do this anyway, and have the dirauths fetch the code from
here? This would work for all platforms then.

agree, the ticket is created. Still upstream releases would miss
important system configuration/dependencies.

I don't understand this.

New packages need to close an ITP. AFAICT that discussion is important
to actually decided whether it makes sense to have the package in Debian.

This only requires that the ITP is filed. This is done.

security updates for backports happen faster?

I'm not sure about that. See dkg's point above though.

Note there's also:

[ ] (optional) upload the package to deb.tpo

Alternatively we could upload it only there, but arma mentioned that only packages that are also in Debian archive go there, cause otherwise would end up unmaintained.

We can even just create a simple APT repository in any web server. As an example I do this here.

comment:9 in reply to:  8 Changed 20 months ago by juga

Replying to juga:

[...]

Do we plan to mandate that dirauths run Debian if they are to have
bandwidth scanners?

No
[...]

I'm not thinking so much about people running it maliciously, but
accidentally and then forgetting about it. This could become a cumulative
problem over time.

what about having big warnings in the package description and command help?
[...]

This only requires that the ITP is filed. This is done.

ok, removing that

[...]

We can even just create a simple APT repository in any web server. As an
example I do this here.

That would not solve the problem of ensuring it is maintained, nor having the Debian keyrings.

comment:10 Changed 20 months ago by juga

Description: modified (diff)
Note: See TracTickets for help on using tickets.