Dear Maintainer,

Whilst golang-github-fluent-fluent-logger-golang builds successfully on unstable/amd64, according to
Debian Policy 4.9 packages may not attempt network access during
a build.

  00:00:00.000000 IP 8cd59013b451.40759 > dnscache.uct.ac.za.domain: 15437+ AAAA? foobarhost.uct.ac.za. (38)
  00:00:00.000050 IP 8cd59013b451.58876 > dnscache.uct.ac.za.domain: 44982+ A? foobarhost.uct.ac.za. (38)
  00:00:00.003746 IP dnscache.uct.ac.za.domain > 8cd59013b451.40759: 15437 NXDomain* 0/1/0 (92)
  00:00:00.004865 IP dnscache.uct.ac.za.domain > 8cd59013b451.58876: 44982 NXDomain* 0/1/0 (92)
  00:00:00.005034 IP 8cd59013b451.60462 > dnscache.uct.ac.za.domain: 42162+ AAAA? foobarhost.chris-lamb.co.uk. (45)
  00:00:00.005038 IP 8cd59013b451.55094 > dnscache.uct.ac.za.domain: 37100+ A? foobarhost.chris-lamb.co.uk. (45)

  [..]

The full build log (including tcpdump output) is attached.


Regards,

Hi Chris,

Thank you for submitting those bugs. I agree that it is a legitimate problem
that needs addressing. However I strongly disagree with severity of those
bugs. Obviously packages should not download anything during build for
security and reproducibility reasons. But here post-build tests attempt to
access internet which is relatively harmless in this context. Indeed tests
trying to access internet from offline environment is hardly a "serious"
problem regardless of what policy says.
Thanks to your bug reports we will eventually address and fix those problems.
In the mean time this should not block testing migrations so I'm lowering
severity of those bugs and I recommend submitting similar bugs with severity
not higher than "important".

---

The most fatal blow to progress is slavery of the intellect. The most
sacred right of humanity is the right to think, and next to the right to
think is the right to express that thought without fear.
        -- Helen H. Gardner, "Men, Women and Gods"

Dmitry wrote:

I guess our differences on this issue are three-fold:

Firstly, network access is not harmless in that it, at the very least, it
leaks the privacy of the developer building something failing some variation
of the DFSG "dissident" test.

(Furthermore, network access can naturally lead to vulnerabilities, although
I'm not claiming that any of the CC'd packages are doing so, am speaking
only to the principle.)

Secondly, retaining such tests provide little value as checks of the
correct functioning of the package given that the package does not FTBFS if
network access is restricted entirely.

In this sense, they engender a false sense of security about the correct
working of the package which is, again, not harmless from a quality assurance
point of view.

Lastly, they aren't really "post-build" as you suggest - they are surely an
integral part of build.

I really don't like to be a stickler for quoting Policy (and using that as a
blunt and inflexible instrument of change/agenda), but I guess that redefining
tests as "post-build" does have the sneaky advantage in that they aren't simple
obvious violations of the paragraph in question. :)


Regards,

I thought the only difference is issues' severity....

No disagreement here. Yet I had to remind that build environment is offline
hence this is only a little problem.

Noted. I'm not against fixing the problem but there are more important issues
to prioritise.

Correct. However removing those tests is an effort that can be done without
rush.
tests that try to access network from offline environment. I certainly prefer
the latter until I can find time to selectively disable tests. I certainly do
not want issues with inflated severity in my queue...

Yes, _optional_ part of the build. ;)  We don't have to run 'em but we want
to.
"prisoners should not attempt to leave locked cells" while reality is that
they can _try_ but attempt would be futile.

I recognise the problems and I agree to fix them but I am not convinced that
those issues should be treated with highest priority. This way or another
practical implications are mild. I hope it makes sense...
---

Men can only be happy when they do not assume that the object of life is
happiness.
        -- George Orwell

Dmitry,

I think this is not a valid argument. Chris is right that the packages
are not following policy, and that they should be fixed. Packaging all
the world software does not serve our users if we are not following our
procedures.

I have seen already a few instances of packages you prepared where you
just skip the tests, or skip failures, instead of fixing the real
problems these are covering. This is not good for Debian and it is
definitely not good for the team.

Please, reconsider your attitude.

Dmitry wrote:

This was not my intention and I have already gone out of my way to avoid such
an impression so I apologise if I could have made this clearer.

I would believe these bugs to be serious, even if Policy was silent on this
issue.

You say "yes", but then you directly counter my point - they are an integral
part of the build and upstream. Whilst you can disable the running of tests,
that's something one must go out of the way to do so.

Quality is not something "we kinda want" in Debian and nor should we conflate
the orthogonal ideas of severity and priority - using words like "rush" make
me more than a little nervous.
[..]

I don't follow what you mean by "build environment is offline", and your
analogy does not seem to apply as the attempts are not futile..


Regards,

No that's all right, you have nothing to apologize for. :)

I'd say they are serious-ish (in a technical sense) and surely worth fixing
yet I still see them as less serious than build failures. I recognize
importance of fixing 'em but I can't treat 'em as a matter of urgency like
severity "serious" suggests.

I was merely trying to provide some context.

Personally I feel uncomfortable when I receive bug that user submits with
higher severity than necessary. Everybody wants their bugs fixed ASAP and
surely from submitter prospective it is important to prioritize their bugs
because they are affected.
Who is the victim here? Build system? Maintainer? It is hard to say who
suffers the most from those bugs that you reported. Whist I strive for
perfection I also need to make the job done. Those bugs will be fixed as soon
as I can (unless team will do it before me) but not sooner than I intend to
address bugs that holding someone from doing something...
IMHO bug's severity should help maintainer to prioritise properly.

I was under impression that build servers do not allow internet access.
If build scripts can access WWW from buildd servers then it would be a much
more serious bug.

Surely there is corner case of "dpkg-buildpackage" that can be vulnerable to
network access during build but even "pbuilder" successfully prevent attempts
to access network.

Even build logs suggest that packages attempt to access network but fail.

I would be much more concerned about the issue if I knew that build
environment allows internet access.

---

Criticism may not be agreeable, but it is necessary. It fulfils the same
function as pain in the human body. It calls attention to an unhealthy
state of things.
        -- Winston Churchill

Hi Dimitry,

I feel like we are talking at cross-purposes and have come to an
impasse to the point that we are going in circles.

You're free to prioritise your packaging efforts as you feel
suitable, I am not asking you to do drop everything to fix these.

Filing a bug--of any severity--is not a comment on the maintainer
and so you shouldn't feel "uncomfortable".

They generally do.


Regards,

That certainly makes those bugs more important but also reveals a more
serious problem. Is there anything you can do to restrict or limit internet
access on buildd servers?

We should not trust build script not to access internet. Even pbuilder limits
network access and build servers should do it as well.

Besides I've just disabled networking test in "franela-goreq" and it was not
even trying to access internet -- the particular test in question was
accessing unrouteable 10.255.255.1 from private subnet to test timeout --
IMHO not much of a threat even on unrestricted build servers to justify
severity "serious" unless we follow the policy to the letter...

---

If liberty means anything at all, it means the right to tell people what
they do not want to hear.
        -- George Orwell

I think you are confused about these bugs. They are being filed against
packages that attempt network connectiviity but do not FTBFS if those
requests fail, so disabling internet access on buildds is an related but
actually different issue altogether.

Furthermore, keeping packages as-is would still leak the privacy of
end-users, deriviates, etc. who are rebuilding packages.


Regards,

Makes sense. Thank you.

Absolutely.

---

He who cannot obey himself will be commanded. That is the nature of living
creatures.
        -- Friedrich Nietzsche

Dear Dmitry,

Gentle ping on this?


Regards,

About what?

---

Moral courage is the most valuable and usually the most absent
characteristic in men.
        -- George S. Patton