Re: tag2upload (git-debpush) service architecture - draft
Hello, On Fri 26 Jul 2019 at 08:50PM +01, Jonathan McDowell wrote: > I've clarified with Ian that despite Sean's blog talking about the > debian-keyring package the dgit infrastructure correctly uses the > keyring in /srv/keyring.debian.org/ as deployed by DSA on the Debian > infrastructure. Right, thanks. Use of that package is just for try-it-on-your-laptop. > The piece of information that I think is missing here (and I've been > able to discover in person) is that the "trusted" piece (all the !s) is > keeping state during the processing of a particular tag/upload. That is, > the trusted component gets handed the tag info, verifies it is sane, > hands it off to the untrusted component to fetch + build a source > package for, then does as much verification as it can that what it gets > back from the untrusted component is the same package/version as > expected. Thanks for this. -- Sean Whitton signature.asc Description: PGP signature
Re: git & Debian packaging sprint report
Hello, On Tue 23 Jul 2019 at 08:13PM +02, Ansgar Burchardt wrote: > There are also other useful properties the current implementation has: > for example the archive contains the artifact that was signed. This can > be checked at a later time unlike a Git tag on salsa.d.o that may or may > not exist in the future. It is always possible to go back to the key > that was used to introduce an artifact without having to trust any > system. I mentioned this to you on IRC, but for the benefit of others reading, the DD-signed tag gets pushed to dgit-repos by the intermediary service, and cannot be deleted from there except by the service admin. Thus, with tag2upload it is possible to go back to the key that introduced the artifact in the way you describe. >> But >> if it's not simple to pick a different hash, SHA-1 preimage resistance is >> reasonable and the other design properties of the system should dominate >> any concern about SHA-1 preimage attacks. > > What about MD5's preimage resistance? We don't really care about > collision attacks after all. I can't see how MD5 is relevant to this discussion. > We have most infrastructure already using SHA-2 and there are > preparations to support newer hashes as well; it is a regression to > introduce a new system bound to SHA1 for the foreseeable future (and > given Git's use of SHA1 their need to require a strong hash is far > less). I think Russ' point is that this regression is a reasonable one, given the benefits against which it is to be traded off. -- Sean Whitton signature.asc Description: PGP signature
Re: file(1) now with seccomp support enabled
Vincas Dargis wrote... > On 2019-07-26 18:59, Christoph Biedl wrote: > > > tl;dr: The file program in unstable is now built with seccomp support > > > enabled, expect breakage in some rather uncommon use cases. > > Interesting, what are these uncommon use cases? Maybe we could confine it > with AppArmor instead, since we have it enabled by default? LD_PRELOAD ruins your day. From the kernel's point of view there is no difference between a syscall coming from the actual application and one coming from the code hooked into it. And while the syscalls done by the first (i.e. file) are more or less known, the latter requires examination of each and every implementation and whitelisting everything. Eventually fakeroot-tcp, wishes to open sockets, something I certainly would not want to whitelist. TTBOMK apparmor would not provide a sane solution for that problem. There still might be another use case: The file program should[citation needed] not write to any file. Reading however must be possible for every item in the entire file system. Christoph signature.asc Description: PGP signature
Re: Sorce only uploads with sbuild (was: Bits from the Release Team)
Shengjing Zhu writes ("Re: Sorce only uploads with sbuild (was: Bits
>from the Release Team)"):
>> On Tue, Jul 23, 2019 at 11:18 PM Sean Whitton
> wrote:
>> > Just `git clean -xdff && dpkg-buildpackage -S` and dput the result,
>or
>> > (easier) `dgit push-source`.
>>
>> Maybe I miss something, sbuild just calls `dpkg-buildpackage -S`. If
>> sbuild doesn't include orig tarball in -2 source.changes, then
>> `dpkg-buildpackage -S` doesn't either.
>>
>> Is there any option of dpkg-buildpackage to include orig tarball in
>-2 changes?
There is. Use -sa as in -S -sa.
Scott K
Re: Salsa.d.o: Please support the implementation request for a global config option to change the default for "Custom CI config path" in Gitlab
Simon McVittie writes: > For those reasons I think something in debian/ would be a better default. > The request in #26 was for debian/.gitlab-ci.yml. I personally think > a non-hidden file (debian/salsa-ci.yml or debian/gitlab-ci.yml) would > make more sense than a hidden file, but that's just bikeshedding > really. The salsa-ci.yml name has the distinct advantage that it is kind to our downstreams, as it makes it obvious where that file is supposed to work. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: Sorce only uploads with sbuild (was: Bits from the Release Team)
Shengjing Zhu writes ("Re: Sorce only uploads with sbuild (was: Bits from the
Release Team)"):
> On Tue, Jul 23, 2019 at 11:18 PM Sean Whitton
> wrote:
> > Just `git clean -xdff && dpkg-buildpackage -S` and dput the result, or
> > (easier) `dgit push-source`.
>
> Maybe I miss something, sbuild just calls `dpkg-buildpackage -S`. If
> sbuild doesn't include orig tarball in -2 source.changes, then
> `dpkg-buildpackage -S` doesn't either.
>
> Is there any option of dpkg-buildpackage to include orig tarball in -2
> changes?
Dunno, I'm afraid. I quickly skimmed the FM and didn't see it. But,
I want to point out (inexplicably Sean didn't mention this):
If you use `dgit push-source' to do your upload you do not need to
worry about this. dgit knows how to ask the archive what .orig
tarballs are already there, and includes the .orig if it is going to
be needed, and not otherwise. Ie dgit doesn't guess based on the
version number. (It will also spot if the .orig you have is not the
same as the one in the archive.)
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Debian and our frenemies of containers and userland repos
Hi, Quoting Simon McVittie (2019-07-26 09:51:24) > schroot is also setuid root, and sbuild relies on this to set up the > build-dependencies anyway, so in principle schroot/sbuild ought to be > able to do something like this: > > - preparation step (as real root, in the chroot, with networking): > - install build-dependencies > - either run bubblewrap or reimplement it > - build step (as ordinary user, entering the chroot as a container, > with no networking): > - dpkg-buildpackage > - cleanup step (as real root, in the chroot): > - destroy session chroot, if used > > Doing that internally in schroot would require it to be actively > developed, but maybe it would be feasible to have code in sbuild that > wrapped bwrap (or even the combination of unshare(1) and setpriv(1)) > around (only) the actual build step? > > With the Debian Policy requirements around not writing to directories other > than /tmp, /var/tmp and the build directory, this would look something like: > > bwrap \ > --unshare-all \ > --ro-bind / / \# or --ro-bind /var/.../my-chroot / > --bind /tmp /tmp \ # or --tmpfs /tmp > --bind /var/tmp /var/tmp \ # or --tmpfs /var/tmp > --bind /build/hello-2.10-2 /build/hello-2.10-2 \ # or wherever the > build directory is kept > --setenv TMPDIR /tmp \ > --dev-bind /dev /dev \ # or --dev /dev for a minimal version > --proc /proc \ > --die-with-parent \ > --chdir /build/hello-2.10-2 \ > dpkg-buildpackage > > This would break any package that relies on being able to run setuid > executables (such as bwrap itself), and get privileges that way, during > its build - but perhaps that's desirable, because buildd operators > probably don't want setuid to be allowed anyway, in case it can be used > to escape the chroot? this is all very interesting! Thanks for writing it up! I will not be spending time on writing a backend using bubble wrap but I'll accept patches if anybody would like to do that work. This could easily be done by extending the current "sudo" chroot mode and wrapping the package build step itself by bubblewrap. Indeed it could probably be already done today by setting the BUILD_ENV_CMND config value to the bwrap line you posted above with the sudo chroot mode. Thanks! cheers, josch signature.asc Description: signature
Re: tag2upload (git-debpush) service architecture - draft
On Wed, Jul 24, 2019 at 02:56:22AM +0100, Ian Jackson wrote: > I wrote this draft design doc / deployment plan for the tag-to-upload > service, perhaps best summarised by Sean like this: > > We designed and implemented a system to make it possible for DDs to > upload new versions of packages by simply pushing a specially > formatted git tag to salsa. For the record I am in favour of this as a service. I'm not a dgit user, but I am a salsa user who pushes release tags there and then uploads to the archive. Reducing this to a single action sounds like less work for me and result in less likelihood of me forgetting a step (either the push to salsa, or sometimes an upload). > Please see this blog post to learn about how it works: > https://spwhitton.name/blog/entry/tag2upload/ I've clarified with Ian that despite Sean's blog talking about the debian-keyring package the dgit infrastructure correctly uses the keyring in /srv/keyring.debian.org/ as deployed by DSA on the Debian infrastructure. > TAG-TO-UPLOAD - DEBIAN - DRAFT DESIGN / DEPLOYMENT PLAN > === > > Overall structure and dataflow > -- > > * Uploader (DD or DM) makes signed git tag (containing metadata >forming instructions to tag2upload service) > > * Uploader pushes said tag to salsa. [1] > > * salsa sends webhook to tag2upload service. > > * tag2upload service > : provides an HTTPS service accessible to salsa's IP addrs > : fishes url and tag name out of webhook json > ! checks that url is basically sane > - retrieves tag data (git shallow clone) > ! parses the tag metadata > ! checks to see if it is relevant > ! verifies signature > ! checks to see if signed by DD, or DM for appropriate package > - obtains relevant git history > - obtains, if applicable, orig tarball from archive > - makes source package > # signs source package and "dgit view" git tag > - pushes history and both tags to dgit git server > - uploads source package to archive > > * archive publishes package as normal The piece of information that I think is missing here (and I've been able to discover in person) is that the "trusted" piece (all the !s) is keeping state during the processing of a particular tag/upload. That is, the trusted component gets handed the tag info, verifies it is sane, hands it off to the untrusted component to fetch + build a source package for, then does as much verification as it can that what it gets back from the untrusted component is the same package/version as expected. Looking at risk factors I think the major ones are dealt with: * The package build is still performed by the buildd, not by this new service, so there shouldn't be exposure to build issues for tag2upload. * tag2upload is making the appropriate checks that the signer of the tag has the right to upload the package to the archive; either is a full DD or is a DM with appropriate DAK ACL rights. * Automated signers for uploads are not new; buildds are already doing this for binary packages. * The complexity is in creating the source package; figuring out the source format type, potentially applying patches etc. This is pushed out to the untrusted component. * Given that the tag signer is independently able to do an upload this does not provide any additional avenue for them to push a nefarious package into the archive. > [1] In principle other git servers would be possible but it would have > to be restricted to ones where we can either avoid, or stop, them > being used as a channel for a DoS attack against the tag2upload > service. If we're hoping to pitch salsa as being the default place for Debian packages to live is limiting this service to salsa not a decent carrot? J. -- "For the effect of psychedelics on the development community, well, there's Enlightenment, isn't there?" -- Adam J. Thornton, asr.
Re: file(1) now with seccomp support enabled
On 2019-07-26 18:59, Christoph Biedl wrote: tl;dr: The file program in unstable is now built with seccomp support enabled, expect breakage in some rather uncommon use cases. Interesting, what are these uncommon use cases? Maybe we could confine it with AppArmor instead, since we have it enabled by default?
Re: does libmyodbc was removed? ther's will no more mysql odbc packages?
On Fri, Jul 26, 2019 at 01:26:52PM -0400, PICCORO McKAY Lenz wrote: > the https://packages.debian.org/search?keywords=libmyodbc show only > for sid and oldstable.. so what will happened.. users now must > compiled own mysql odbc? It's in sid, so no? Also, if you use https://tracker.debian.org/pkg/libmyodbc instead of packages.debian.org, you can see the reasons why it's not in testing. -- WBR, wRAR signature.asc Description: PGP signature
does libmyodbc was removed? ther's will no more mysql odbc packages?
the https://packages.debian.org/search?keywords=libmyodbc show only for sid and oldstable.. so what will happened.. users now must compiled own mysql odbc? Lenz McKAY Gerardo (PICCORO) http://qgqlochekone.blogspot.com
Re: Salsa.d.o: Please support the implementation request for a global config option to change the default for "Custom CI config path" in Gitlab
On Fri, 26 Jul 2019 at 17:17:02 +0200, Bastian Blank wrote: > On Thu, Jul 25, 2019 at 02:31:55PM +0200, Daniel Leidert wrote: > > Therefor some time ago it had > > been requested to instead change the default at salsa.d.o system wide. > > Why do you think we would change it _if_ this option would exist? This was requested in the past in https://salsa.debian.org/salsa/support/issues/26, and some people (including me) interpreted the reply as "no, but only because upstream doesn't have that feature". Was that interpretation wrong? The default of ./.gitlab.yml is problematic for Salsa *because* it's the upstream default, and git repositories on Salsa are most commonly used for Debian packaging where we try to minimize delta vs upstream source code: - Upstream projects developed on a Gitlab instance often include a ./.gitlab.yml that is designed to run on their infrastructure, not ours. If it works on our infrastructure, it's a waste of runner time: we want to test our packages, not the unmodified upstream source code. If it doesn't work on our infrastructure then it just gets in the way. - We can't remove ./.gitlab.yml from branches that match the upstream source code (e.g. upstream/* in DEP-14) because that would make those branches not match the upstream source code any more. - Anyone who wants to preserve the dgit-like property that the contents of git match the contents of the source package, and is using a patches-applied repository layout, can't remove ./.gitlab.yml without having a somewhat pointless commit in the source package that deletes it. - Anyone who wants to preserve the dgit-like property that the contents of git match the contents of the source package, and is using a patches-unapplied repository layout (e.g. gbp pq), can't remove ./.gitlab.yml at all. For those reasons I think something in debian/ would be a better default. The request in #26 was for debian/.gitlab-ci.yml. I personally think a non-hidden file (debian/salsa-ci.yml or debian/gitlab-ci.yml) would make more sense than a hidden file, but that's just bikeshedding really. Obviously the maintainers of individual packages can always configure their individual Gitlab projects, but that's an extra step to remember to take when creating a new package, the fact that it's per-project means there is no obvious value for what the different setting should be (reducing consistency between packages), and the fact that it's out-of-band Gitlab configuration conflicts with the general principle of keeping as much as possible in a VCS. smcv
Re: Salsa.d.o: Please support the implementation request for a global config option to change the default for "Custom CI config path" in Gitlab
Hi, On 19-07-26 17:17:02, Bastian Blank wrote: > Why do you think we would change it _if_ this option would exist? Because, chances are, you want to test if the package builds fine, for example, instead of running the upstream CI config. (Yes, I'm aware that it's possible to make this change per repo.) Cheers, Georg
Re: file(1) now with seccomp support enabled
Christoph Biedl wrote... > tl;dr: The file program in unstable is now built with seccomp support > enabled, expect breakage in some rather uncommon use cases. Several issues popped up in the last days as a result of that change, and in spite of some band-aiding to current implementation of seccomp in the file program creates way more trouble than I am willing to ignore. So, sadly, I've reverted seccomp support for the time being to avoid further disruption of the bullseye development. However, Helmut Grohne has suggested to confine only that part of the code that is most likely susceptible to vulnerabilities, details in #932762, and I agree this is possibly the better way to go. This requires co-ordination with upstream and will take a bit of time. Christoph signature.asc Description: PGP signature
Re: regarding non-free firmware for wi-fi and ethernet
On 25/07/19 14:00, Abibula Aygun wrote: > > Hello Debian Team, Hi there :-) > We have an little problem. > The installer can't detect many simple wi-fi or ethernet hardware. > Things that was ok on Stretch version. Are you able to tell us WHICH wifi / ethernet hardware worked without non-free drivers in Stretch and now needs drivers from non-free for Buster? > What can we do to insert the Firmwares on our distribution ? The same as we do - have a "non-free" area in your archive (but satisfy yourselves that you are free to distribute) > You have an unofficial Debian with all non-free firmwares. As far as i > know is ok to include in AcademiX distro the > non-free firmwares for wi-fi and ethernet without alterate the licence > of the manufacturer or the code of the firmware. > Anyway, the non-free firmwares are used by the installer an not by final > installed system. I am somewhat surprised if this is correct... Regards /Andy
Re: Salsa.d.o: Please support the implementation request for a global config option to change the default for "Custom CI config path" in Gitlab
Hi Daniel On Thu, Jul 25, 2019 at 02:31:55PM +0200, Daniel Leidert wrote: > Therefor some time ago it had > been requested to instead change the default at salsa.d.o system wide. Why do you think we would change it _if_ this option would exist? Bastian Salsa admin -- Women professionals do tend to over-compensate. -- Dr. Elizabeth Dehaver, "Where No Man Has Gone Before", stardate 1312.9.
Bug#933070: ITP: pydevd -- Sources for the debugger used in PyDev, PyCharm and VSCode Python
Package: wnpp Severity: wishlist Owner: William Grzybowski * Package name: pydevd Version : 1.6.1 Upstream Author : Fabio Zadrozny * URL : https://github.com/fabioz/PyDev.Debugger/ * License : EPL Programming Lang: Python Description : Sources for the debugger used in PyDev, PyCharm and VSCode Python In general, the debugger backend should NOT be installed separately if you're using an IDE which already bundles it (such as PyDev or PyCharm). It is however available in PyPi so that it can be installed for doing remote debugging with pip -- so, when debugging a process which runs in another machine, it's possible to pip install pydevd and in the code use pydevd.settrace(host='10.1.1.1') to connect the debugger backend to the debugger UI running in the IDE (whereas previously the sources had to be manually copied from the IDE installation). -- Its useful for remote debugging. I plan to maintain it within DPMT.
Bug#933058: ITP: python-dbussy -- Python 3 bindings for libdbus
Package: wnpp Severity: wishlist Owner: "W. Martin Borgert" * Package name: python-dbussy Version : 1.1 Upstream Author : Lawrence D'Oliveiro * URL : https://github.com/ldo/dbussy * License : LGPL-2.1+ Programming Lang: Python Description : Python 3 bindings for libdbus Pure-Python binding for D-Bus, built around libdbus. This Python binding supports hooking into event loops via Python’s standard asyncio module. I will maintain the package within the Python team (DPMT).
Re: Debian and our frenemies of containers and userland repos
On Fri, 26 Jul 2019 at 07:34:58 +0200, Johannes Schauer wrote: > Sadly > this functionality requires a horribly complicated fork/syscall dance [1] > which > I also had to copy to mmdebstrap because no existing tool seemed to do it > already. bubblewrap might do the same dance, or at least a compatible dance? It won't be suitable for mmdebstrap and general full-system containers (there's only one uid and one gid in the container, with everything visible from the host system mapped to 'nobody') but it might be suitable for more restricted uses like building a Debian package. > But to unshare all the namespaces, even schroot would need #898446 to be > fixed. On systems that restrict user namespace creation (Debian, Arch Linux, RHEL), bubblewrap gets round this by being setuid root. To avoid reopening the same security vulnerabilities that would be available via unrestricted user namespace creation, it severely limits what it is willing to do/allow in user-supplied code in the container, in particular setting NO_NEW_PRIVS so that the setuid bit no longer works. schroot is also setuid root, and sbuild relies on this to set up the build-dependencies anyway, so in principle schroot/sbuild ought to be able to do something like this: - preparation step (as real root, in the chroot, with networking): - install build-dependencies - either run bubblewrap or reimplement it - build step (as ordinary user, entering the chroot as a container, with no networking): - dpkg-buildpackage - cleanup step (as real root, in the chroot): - destroy session chroot, if used Doing that internally in schroot would require it to be actively developed, but maybe it would be feasible to have code in sbuild that wrapped bwrap (or even the combination of unshare(1) and setpriv(1)) around (only) the actual build step? With the Debian Policy requirements around not writing to directories other than /tmp, /var/tmp and the build directory, this would look something like: bwrap \ --unshare-all \ --ro-bind / / \# or --ro-bind /var/.../my-chroot / --bind /tmp /tmp \ # or --tmpfs /tmp --bind /var/tmp /var/tmp \ # or --tmpfs /var/tmp --bind /build/hello-2.10-2 /build/hello-2.10-2 \ # or wherever the build directory is kept --setenv TMPDIR /tmp \ --dev-bind /dev /dev \ # or --dev /dev for a minimal version --proc /proc \ --die-with-parent \ --chdir /build/hello-2.10-2 \ dpkg-buildpackage This would break any package that relies on being able to run setuid executables (such as bwrap itself), and get privileges that way, during its build - but perhaps that's desirable, because buildd operators probably don't want setuid to be allowed anyway, in case it can be used to escape the chroot? smcv
