dpkg-vendor --query Vendor returns Debian - should return TurnKey Linux #196

Closed
JedMeister opened this Issue Apr 22, 2014 · 8 comments

Comments

Projects
None yet
3 participants
@JedMeister
Owner

JedMeister commented Apr 22, 2014

dpkg-vendor --query Vendor According to Debian if this prints 'Debian' then you need to patch base-files in your distribution to add a new file in /etc/dpkg/origins/example containing information about your distribution...

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

@JedMeister JedMeister added bug labels Apr 22, 2014

@JedMeister JedMeister modified the milestones: 14.0, 13.1 Jun 7, 2014

@JedMeister JedMeister modified the milestones: 14.0, 13.1 Apr 17, 2015

@JedMeister JedMeister referenced this issue in turnkeylinux/common Apr 17, 2015

Merged

Fix dpkg-vendor output #12

@JedMeister JedMeister assigned JedMeister and unassigned alonswartz Apr 17, 2015

@JedMeister JedMeister modified the milestones: 14.1, 14.0 Jul 14, 2015

@JedMeister JedMeister modified the milestones: 14.2, 14.1 Dec 19, 2015

@JedMeister

This comment has been minimized.

Show comment Hide comment
@JedMeister

JedMeister Aug 4, 2017

Owner

Hey @lamby - do you have any advice on this?

I was pretty keen to update this ages ago, but we were concerned about what might break if we did this. As noted in turnkeylinux/common#12, sometime ago there were reports of some packages breaking after this was done. I recall reading someone suggesting that we should do it anyway, then issue bugs against any packages that break, but we'd rather not have those sort of issues if we can avoid it, so would rather wait until that concern is eliminated (or at least reduced).

Do you have any insight/suggestions/etc?

[update] FWIW, I'm going to apply this to my (now Stretch) laptop and will report back if I hit any issues.

Owner

JedMeister commented Aug 4, 2017

Hey @lamby - do you have any advice on this?

I was pretty keen to update this ages ago, but we were concerned about what might break if we did this. As noted in turnkeylinux/common#12, sometime ago there were reports of some packages breaking after this was done. I recall reading someone suggesting that we should do it anyway, then issue bugs against any packages that break, but we'd rather not have those sort of issues if we can avoid it, so would rather wait until that concern is eliminated (or at least reduced).

Do you have any insight/suggestions/etc?

[update] FWIW, I'm going to apply this to my (now Stretch) laptop and will report back if I hit any issues.

@JedMeister JedMeister modified the milestones: 15.0, 14.2 Aug 4, 2017

@lamby lamby self-assigned this Aug 4, 2017

@lamby

This comment has been minimized.

Show comment Hide comment
@lamby

lamby Aug 4, 2017

Member

[adding assign so I don't lose it]

Member

lamby commented Aug 4, 2017

[adding assign so I don't lose it]

@lamby

This comment has been minimized.

Show comment Hide comment
@lamby

lamby Aug 15, 2017

Member

@JedMeister

First up, why do you want this? :) It's hardly really exposed to the user - the dpkg-vendor system is quite obscure, even for a DD.

Secondly, where is your existing origin file? I can see the symlink foo, but I can't find the file you were inserting. Did it contain Parent: Debian ooi?

someone on the mailing list (a guy from Tails perhaps?) said that it broke some package installs so they changed it back

Thirdly, I think getting more details here is the next step. What broke..? What was the impact..? It might be fixable elsewhere.

Member

lamby commented Aug 15, 2017

@JedMeister

First up, why do you want this? :) It's hardly really exposed to the user - the dpkg-vendor system is quite obscure, even for a DD.

Secondly, where is your existing origin file? I can see the symlink foo, but I can't find the file you were inserting. Did it contain Parent: Debian ooi?

someone on the mailing list (a guy from Tails perhaps?) said that it broke some package installs so they changed it back

Thirdly, I think getting more details here is the next step. What broke..? What was the impact..? It might be fixable elsewhere.

@JedMeister

This comment has been minimized.

Show comment Hide comment
@JedMeister

JedMeister Aug 16, 2017

Owner

@lamby


First up, why do you want this? :) It's hardly really exposed to the user - the dpkg-vendor system is quite obscure, even for a DD.

Because Paul Wise (pabs) asked us to, back when we first joined the Debian Derivatives Census in 2014:

The page is missing a dpkg vendor field. It is important that
Debian derivatives set this properly on installed systems and
mention the value of the field in the derivatives census.

It seems to be a pretty common request of freshly signed up Debian Derivatives; as per:
https://wiki.debian.org/Derivatives/CensusQA#dpkg_vendor_issues


Secondly, where is your existing origin file? I can see the symlink foo, but I can't find the file you were inserting. Did it contain Parent: Debian ooi?

The pull request I originally issued is here
But yes it does contain Parent: Debian (see here)


someone on the mailing list (a guy from Tails perhaps?) said that it broke some package installs so they changed it back

Thirdly, I think getting more details here is the next step. What broke..? What was the impact..? It might be fixable elsewhere.

Fair and reasonable point. In retrospect, I probably should have chased the original conversation up and posted that at... Also as context, Paul suggested that if anything breaks, then those particular packages should have bugs issued against them.

FWIW, it was hLinux (not Tails) that reported issues. The full thread (inc my 2c) starts here, but the specific bit that raised my concerns was posted by Josh of hLinux:

We originally modified /etc/dpkg/origins/default to point at our own
file that stated: "Vendor = hlinux" In doing so we discovered that
this modified lsb_release and caused some applications to fail to
install as they were unable to determine the underlying distribution.
The prime example is OpenStack's diskimage-builder was expecting
either Debian or Ubuntu and failed with other values. Is there a
better method? Or should we instead be working with the software
vendors to not hard code specific actions based off this value?

And Patrick from Whonix (where my erroneous memory of Tails probably comes from):

"apt-get source package" will show "dpkg-source: warning: failed to
verify signature"

https://www.whonix.org/wiki/Download#.22apt-get_source_package.22_will_show_.22dpkg-source:_warning:_failed_to_verify_signature.22

Owner

JedMeister commented Aug 16, 2017

@lamby


First up, why do you want this? :) It's hardly really exposed to the user - the dpkg-vendor system is quite obscure, even for a DD.

Because Paul Wise (pabs) asked us to, back when we first joined the Debian Derivatives Census in 2014:

The page is missing a dpkg vendor field. It is important that
Debian derivatives set this properly on installed systems and
mention the value of the field in the derivatives census.

It seems to be a pretty common request of freshly signed up Debian Derivatives; as per:
https://wiki.debian.org/Derivatives/CensusQA#dpkg_vendor_issues


Secondly, where is your existing origin file? I can see the symlink foo, but I can't find the file you were inserting. Did it contain Parent: Debian ooi?

The pull request I originally issued is here
But yes it does contain Parent: Debian (see here)


someone on the mailing list (a guy from Tails perhaps?) said that it broke some package installs so they changed it back

Thirdly, I think getting more details here is the next step. What broke..? What was the impact..? It might be fixable elsewhere.

Fair and reasonable point. In retrospect, I probably should have chased the original conversation up and posted that at... Also as context, Paul suggested that if anything breaks, then those particular packages should have bugs issued against them.

FWIW, it was hLinux (not Tails) that reported issues. The full thread (inc my 2c) starts here, but the specific bit that raised my concerns was posted by Josh of hLinux:

We originally modified /etc/dpkg/origins/default to point at our own
file that stated: "Vendor = hlinux" In doing so we discovered that
this modified lsb_release and caused some applications to fail to
install as they were unable to determine the underlying distribution.
The prime example is OpenStack's diskimage-builder was expecting
either Debian or Ubuntu and failed with other values. Is there a
better method? Or should we instead be working with the software
vendors to not hard code specific actions based off this value?

And Patrick from Whonix (where my erroneous memory of Tails probably comes from):

"apt-get source package" will show "dpkg-source: warning: failed to
verify signature"

https://www.whonix.org/wiki/Download#.22apt-get_source_package.22_will_show_.22dpkg-source:_warning:_failed_to_verify_signature.22

@lamby

This comment has been minimized.

Show comment Hide comment
@lamby

lamby Aug 16, 2017

Member

@JedMeister

Thank you so much for the prompt, detailed and well-researched reply. :)

I think we should simply apply this change and fix any breakage. Whilst it might break some random third-party installer, we cannot work around all the problems in those especially as they cause so many other (bigger) problems such as installing to weird paths outside of the package management system.

"apt-get source package" will show "dpkg-source: warning: failed to
verify signature"

Sounds like a different problem. (and your link doesn't seem to link to that quote?)

Member

lamby commented Aug 16, 2017

@JedMeister

Thank you so much for the prompt, detailed and well-researched reply. :)

I think we should simply apply this change and fix any breakage. Whilst it might break some random third-party installer, we cannot work around all the problems in those especially as they cause so many other (bigger) problems such as installing to weird paths outside of the package management system.

"apt-get source package" will show "dpkg-source: warning: failed to
verify signature"

Sounds like a different problem. (and your link doesn't seem to link to that quote?)

@JedMeister

This comment has been minimized.

Show comment Hide comment
@JedMeister

JedMeister Aug 16, 2017

Owner

"apt-get source package" will show "dpkg-source: warning: failed to
verify signature"

Sounds like a different problem. (and your link doesn't seem to link to that quote?)

Sorry the link was part of Patrick's message, I didn't link to the post where he said that; FWIW, here it is.

Ok awesome, let's just do that then!

Owner

JedMeister commented Aug 16, 2017

"apt-get source package" will show "dpkg-source: warning: failed to
verify signature"

Sounds like a different problem. (and your link doesn't seem to link to that quote?)

Sorry the link was part of Patrick's message, I didn't link to the post where he said that; FWIW, here it is.

Ok awesome, let's just do that then!

@JedMeister

This comment has been minimized.

Show comment Hide comment
@JedMeister

JedMeister Aug 16, 2017

Owner

turnkeylinux/common#12 has been merged. Closing this.

Owner

JedMeister commented Aug 16, 2017

turnkeylinux/common#12 has been merged. Closing this.

@JedMeister JedMeister closed this Aug 16, 2017

@JedMeister

This comment has been minimized.

Show comment Hide comment
@JedMeister

JedMeister Aug 17, 2017

Owner

For full reference (may not be 100% relevant, but posting it anyway...):

On 07/05/15 21:19, David Kalnischkies wrote:

On Wed, May 06, 2015 at 09:30:32PM +0800, Paul Wise wrote:

On Wed, May 6, 2015 at 8:46 PM, Patrick Schleizer wrote:

"apt-get source package" will show "dpkg-source: warning: failed to
verify signature"

https://www.whonix.org/wiki/Download#.22apt-get_source_package.22_will_show_.22dpkg-source:_warning:_failed_to_verify_signature.22

I still think that is a bug that should be filed, apt should be using
the trusted keyring for verifying source packages, vendor information
should not be involved at all.

dpkg-source involves vendor information as the dsc files it is checking
the signature for isn't signed by a key known to apt (at least in the
general case), but the currently used key of the uploader of said
package. Debian provides the large debian-keyring package and dpkg is
looking for it to do its bidding (see also dpkg-source manpage), but
that isn't failsafe from an apt perspective: The keys used to sign this
dsc file could be expired in the meantime, the uploader no longer in the
keyring (ressigned DD/DM) or not yet (new DD/DM) or not with this key.

Neither is a problem for 'apt-get source' as it establishes a trustchain
where the repository creator checked the dsc file. It is an additional
check if it can be done and can't hurt (well, it can scare people if one
of the cases mentioned above happens or with this warning), but its also
scaring me to disable such checks with '--no-check' by default as
someone will probably scream at me for doing it when the next security
bug is found. I am a bit undecided at the moment…

Btw: If you happen to have a package similar to debian-keyring
containing the keys of your developers, you could ask dpkg to support
it. The scripts/Dpkg/Vendor/ directory in dpkg sources is pretty sparsly
populated at the moment… (I am not a dpkg dev through, so I can't help
with that, best to ask them).

Oh, and only slightly related: APT has a vendor/ directory as well:
https://anonscm.debian.org/cgit/apt/apt.git/tree/vendor/README

Best regards

David Kalnischkies

Owner

JedMeister commented Aug 17, 2017

For full reference (may not be 100% relevant, but posting it anyway...):

On 07/05/15 21:19, David Kalnischkies wrote:

On Wed, May 06, 2015 at 09:30:32PM +0800, Paul Wise wrote:

On Wed, May 6, 2015 at 8:46 PM, Patrick Schleizer wrote:

"apt-get source package" will show "dpkg-source: warning: failed to
verify signature"

https://www.whonix.org/wiki/Download#.22apt-get_source_package.22_will_show_.22dpkg-source:_warning:_failed_to_verify_signature.22

I still think that is a bug that should be filed, apt should be using
the trusted keyring for verifying source packages, vendor information
should not be involved at all.

dpkg-source involves vendor information as the dsc files it is checking
the signature for isn't signed by a key known to apt (at least in the
general case), but the currently used key of the uploader of said
package. Debian provides the large debian-keyring package and dpkg is
looking for it to do its bidding (see also dpkg-source manpage), but
that isn't failsafe from an apt perspective: The keys used to sign this
dsc file could be expired in the meantime, the uploader no longer in the
keyring (ressigned DD/DM) or not yet (new DD/DM) or not with this key.

Neither is a problem for 'apt-get source' as it establishes a trustchain
where the repository creator checked the dsc file. It is an additional
check if it can be done and can't hurt (well, it can scare people if one
of the cases mentioned above happens or with this warning), but its also
scaring me to disable such checks with '--no-check' by default as
someone will probably scream at me for doing it when the next security
bug is found. I am a bit undecided at the moment…

Btw: If you happen to have a package similar to debian-keyring
containing the keys of your developers, you could ask dpkg to support
it. The scripts/Dpkg/Vendor/ directory in dpkg sources is pretty sparsly
populated at the moment… (I am not a dpkg dev through, so I can't help
with that, best to ask them).

Oh, and only slightly related: APT has a vendor/ directory as well:
https://anonscm.debian.org/cgit/apt/apt.git/tree/vendor/README

Best regards

David Kalnischkies

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment