[pkg-golang-devel] [pkg-go] Security support for packages written in Go

Michael Hudson-Doyle michael.hudson at canonical.com
Thu Apr 14 07:26:10 UTC 2016


On 14 April 2016 at 19:16, Michael Stapelberg <stapelberg at debian.org> wrote:
> Thanks for the patch, it’s now merged and uploaded.

Awesome, thanks for that.

> I’d prefer if you could send such patches in a bug report instead of to
> mailing lists which I don’t actively read :).

Noted!

> In fact, I’d say it’s long overdue to make this package team-maintained.

Sounds sensible.

> The repository is already in
> collab-maint, so if you want to make the necessary changes, please just go
> ahead.

I don't think I can commit to collab-maint (I'm not a DD or even a DM yet).

Cheers,
mwh

> With regards to the original post, I think we have the same issue that the
> haskell packaging community has, since they have the same linking model.
> I’ve talked to Joachim Breitner (nomeata) about this a couple years ago and
> he mentioned they have some tooling which addresses the issue in a
> sufficient way.
>
> I’d suggest to tackle the problem the same way for Go, and maybe share some
> tools if applicable. That said, I won’t have time or motivation to do any of
> the work required for this, so volunteers are very welcome.
>
> On Thu, Apr 14, 2016 at 3:08 AM, Michael Hudson-Doyle
> <michael.hudson at canonical.com> wrote:
>>
>> On 13 April 2016 at 21:05, Michael Hudson-Doyle
>> <michael.hudson at canonical.com> wrote:
>> > On 13 April 2016 at 17:07, Tianon Gravi <admwiggin at gmail.com> wrote:
>> >> On 12 April 2016 at 21:39, Michael Hudson-Doyle
>> >> <michael.hudson at canonical.com> wrote:
>> >>> We could do it without 1) and the consequent re-uploading of every go
>> >>> library by using dpkg-query --search a lot, which would be slow I
>> >>> guess, but maybe could be done as a fallback?
>> >>
>> >> I still asking dpkg about file/directory package ownership should be
>> >> our primary means of generating this field -- the metadata that dpkg
>> >> itself tracks about "which package provided
>> >> /usr/share/gocode/src/abc/xyz which I just compiled against" will
>> >> always be correct (due to the fact that it really is the single proper
>> >> source of truth for such information), where some arbitrary metadata
>> >> we add not only clutters up the package metadata as has been
>> >> discussed, but much more importantly will have a tendency to "drift"
>> >> from the truth, which is something that IMO we shouldn't tolerate for
>> >> a field whose primary purpose is knowing when it's necessary to
>> >> rebuild, especially for security fixes.  Even for really large
>> >> packages like Docker (to choose an example that I know off the top of
>> >> my head is reasonably hefty WRT deps) we're only talking about maybe
>> >> ~200 of these queries at the outside end, and only at build-time, and
>> >> only once per build, which IMO is in the realm of reasonable to avoid
>> >> yet again uploading a minor fix to every package (moving the metadata
>> >> over to the binary packages when we still haven't added the existing
>> >> source package metadata to all of them yet) with information that will
>> >> have a potential for drifting from the truth or for being too limited
>> >> (single package providing multiple namespaces after a repo move, for
>> >> example).
>> >
>> > Yes, all that seems fair. Something like this?
>> > http://paste.ubuntu.com/15806327/ -- it's pretty terrible perl, but
>> > it's actually arguably simpler than what dh_golang does already!
>>
>> FWIW, I sent a better version of this patch:
>>
>> http://lists.alioth.debian.org/pipermail/pkg-go-maintainers/Week-of-Mon-20160411/004304.html
>>
>> Cheers,
>> mwh
>
>
>
>
> --
> Best regards,
> Michael



More information about the pkg-golang-devel mailing list