Re: debian/copyright in source package
On Sun, Aug 23, 2015 at 18:09:16 +0200, Thorsten Alteholz wrote: On Sun, 23 Aug 2015, Julien Cristau wrote: FWIW I disagree with this change, I don't think making a new requirement for source packages is the way to solve NEW review workflow. Oh, lintian already complains about a missing debian/copyright in the source package. So this change is not a new requirement but is only meant as a clarification. lintian only emits a warning. Which is IMO perfectly OK to ignore. Cheers, Julien signature.asc Description: Digital signature
Re: debian/copyright in source package
On Sun, 23 Aug 2015, Julien Cristau wrote: On Sun, Aug 23, 2015 at 18:09:16 +0200, Thorsten Alteholz wrote: On Sun, 23 Aug 2015, Julien Cristau wrote: FWIW I disagree with this change, I don't think making a new requirement for source packages is the way to solve NEW review workflow. Oh, lintian already complains about a missing debian/copyright in the source package. So this change is not a new requirement but is only meant as a clarification. lintian only emits a warning. Which is IMO perfectly OK to ignore. But policy says that there should be such a copyright file. Violating such a clause is at least an important bug. As a maintainer you only need to take care of serious bugs, so of course you can ignore it ... From my point of view this is still a bad thing. In any case you have to collect all information for the binary package. Doing this during binary package building, means that all buildds have to do this (maybe even different versions for each package). Wouldn't it make more sense to build it only once and put it in the source package? Strictly speaking, while checking the copyright file of a binary package, one has to determine first what files from the source package are needed to create that binary package. I am not sure whether this can be done reliable with any automatism. So it adds another manual step to the NEW review. Further, up to now most packages have this debian/copyright. So processing such packages is more or less routine. Any disturbance of this routine means that processing needs more time ... Thorsten
Re: debian/copyright in source package
On Sun, 23 Aug 2015, Julien Cristau wrote: FWIW I disagree with this change, I don't think making a new requirement for source packages is the way to solve NEW review workflow. Oh, lintian already complains about a missing debian/copyright in the source package. So this change is not a new requirement but is only meant as a clarification. Thorsten
Bug#796642: debian-policy: hardening is an afterthought and should never be
Control: tags -1 = On Sun, Aug 23, 2015 at 12:46:22AM -0500, Richard Jasmin wrote: SELinux ENABLED and ENFORCING and INSTALLED WITH SeTroubleshoot [like Fedora has] This is not a question for policy. SELinux is not enabled by default in Debian because no one has gone to the effort of ensuring there is an SELinux policy in Debian that could work out of the box. There is nothing that policy needs to say on this question. If you are interested in seeing SELinux enabled by default in Debian, I recommend you use the Debian mailing lists (debian-devel is a good starting point) to find other people you could collaborate with to make this possible. Harden flags set AND ENFORCED on build environment(harden package) There is no way to enforce the use of hardening flags. Debian does already enable hardening flags by default, as shown by the output of 'dpkg-buildflags'. Use of RELRO and PIE where possible relro is already part of the default hardening flags. Maintainers already use PIE where it's believed possible. So what change are you looking for? NOEXEC and NOSUID on /tmp and /var/tmp dpkg needs to unpack maintainer scripts and execute them, which means unpacking to /tmp. This will never be supported so long as Debian uses dpkg. VA.randomize(HEAP?) set by default in /etc/sysctl.conf [I have many tweaks here, some for gigabit ethernet] This should be filed as a bug report against the procps package, not against policy. ENCRYPTED SWAP enabled by DEFAULT with a RANDOM key This should be discussed on debian-devel or with the debian-installer maintainers on debian-boot, not in policy. /etc/securetty set to near nothing or nothing with comments on why nothing is here and the local login methods commented. The right package for this suggestion would be the login package. However this is a nonsense suggestion, which I expect the login maintainers to rightly reject. The purpose of this file is to declare which terminals have a secure path to the host so that login knows whether or not to allow root logins. If you want to completely disallow root logins on your system, configure your system without a root password - this has nothing to do with /etc/securetty. ufw/gufw installed and set on startup fail2ban installed and base configured Default package selections: -devel or -boot, not -policy. password backups disabled Should be a bug report on the shadow package grub password protection should work (it doesnt and not only that but users and admins should have a clear cut method to enable this) Should be a bug report on the grub2 package (but possibly this is bug #545163) Documentation of mainline system installed and linked to in ~/Desktop. (Like a pdf of the debian handbook...) I don't know what documentation would be suitable here. If you have a specific recommendation (whether that's the Debian handbook or otherwise), you should probably bring this up as a bug report on the gnome package. non-free video (and other hardware) detection and installation help offered post install [like ubuntu has] It severely harms your credibility that you are complaining that Debian is not secure, and then go on to insist that Debian should make it easier to install unauditable non-free drivers. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
Processed: Re: Bug#796642: debian-policy: hardening is an afterthought and should never be
Processing control commands: tags -1 = Bug #796642 [debian-policy] debian-policy: hardening is an afterthought and should never be Removed tag(s) security, upstream, and newcomer. -- 796642: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796642 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Re: Bug#796660: Binaries in binary packages match the architecture
* Simon McVittie: On 23/08/15 11:31, Florian Weimer wrote: For example, shipping i386 binaries instead of amd64 binaries is not acceptable, even though these programs might run with the default Debian kernel. This does not match current practice in all cases: multilib (lib32gcc, etc.) has a lot of i386 libraries in x86_64 packages and similar situations. Things like wine and mingw also don't work without foreign binaries, although those at least aren't binaries from a Debian architecture. Shouldn't those go away because we now have true multiarch? Is there a problem you are aiming to solve with this requirement? Do any maintainers not realise that packaging wrong-architecture binaries without a good reason is undesired? Yes, smlnj.
Re: debian/copyright in source package
On Thu, Aug 20, 2015 at 11:44:10 +0900, Charles Plessy wrote:
Dear Santiago and everybody,
how about the following ? (in section 4.5)
--- a/policy.sgml
+++ b/policy.sgml
@@ -1822,12 +1822,16 @@ zope.
sect id=dpkgcopyright
headingCopyright: filedebian/copyright/file/heading
p
Every {+source+} package must be accompanied by a verbatim copy
of its copyright information and distribution license in the
file
[-file/usr/share/doc/varpackage/var/copyright/file-]{+filedebian/copyright/filefootnote+}
{+ The filedebian/copyright/file file must be present, to+}
{+ ease the review of new packages and to facilitate automatic+}
{+ extraction of this information. It may be generated from+}
{+ templates, but not at build time./footnote+}
(see ref id=copyrightfile for further details). Also see
ref id=pkgcopyright for further considerations related to
copyrights for packages.
/p
/sect
sect
Even after that change, the sentence Every package must be accompanied by a
verbatim copy of its copyright information and distribution license in the
file
/usr/share/doc/package/copyright still appears twice in the Policy.
FWIW I disagree with this change, I don't think making a new requirement
for source packages is the way to solve NEW review workflow.
Cheers,
Julien
signature.asc
Description: Digital signature
Re: Bug#796660: Binaries in binary packages match the architecture
On 23/08/15 11:31, Florian Weimer wrote: For example, shipping i386 binaries instead of amd64 binaries is not acceptable, even though these programs might run with the default Debian kernel. This does not match current practice in all cases: multilib (lib32gcc, etc.) has a lot of i386 libraries in x86_64 packages and similar situations. Things like wine and mingw also don't work without foreign binaries, although those at least aren't binaries from a Debian architecture. Is there a problem you are aiming to solve with this requirement? Do any maintainers not realise that packaging wrong-architecture binaries without a good reason is undesired? Policy doesn't need to forbid every possible packaging error. S
Bug#796660: Binaries in binary packages match the architecture
Package: debian-policy It seems to me that a requirement is missing from the policy that binaries (DSOs and executables) which are intended to run on the host must be located in a binary package, and the architecture of the binary package must match the DSO/executable architecture. For example, shipping i386 binaries instead of amd64 binaries is not acceptable, even though these programs might run with the default Debian kernel.
Re: debian/copyright in source package
On Sun, Aug 16, 2015 at 06:41:12PM +0100, Simon McVittie wrote: via a script that indents the license text by 1 space and puts . on blank lines. This sounds like a thing caused solely by DEP-5 (which some people tend to ignore, because of such things). -- WBR, wRAR signature.asc Description: Digital signature
Bug#796642: debian-policy: hardening is an afterthought and should never be
* Steve Langasek: Harden flags set AND ENFORCED on build environment(harden package) There is no way to enforce the use of hardening flags. There is a way, involving multiple steps: 1. Put -grecord-gcc-switches into the hardening flags. 2. Make debuginfo packages mandatory. 3. Make full debuginfo coverage for ELF objects mandatory. This needs tooling which does not exist yet. 4. Check that all record GCC switches (see step 1) contain hardening flags. 5. Add the the checks to Lintian. Steps 2 and 3 are the difficult ones. There is independent work on automatic debuginfo package generation, so step 2 might eventually become a possibility. Step 3 should be relatively straightforward to write for someone who is familiar with elfutils and DWARF. In fact, eu-checksec is on my long-term TODO list, and steps 3 and 4 could be part of that.
