Re: [RFR] Bits draft for Lintian 2.5.12
* Niels Thykier , 2013-04-17, 21:51: lintian (>= 2.5.12), lintian (<< 2.5.13~) "2.5.12" could have a tilde too (although it's arguably less important than for the other version). -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130417215644.ga9...@jwilk.net
Bug#704197: Please review: systemd checks
Hi Niels,
Niels Thykier writes:
> I thought this was safe, but it does have an issue as well. Consider
> symlink chaining:
>
> safe-symlink -> unsafe-symlink
> unsafe-symlink -> ../../../../etc/passwd
>
> $path->link_resolved will approve "safe-symlink" because it can be
> resolved safely. However, it does not check that the target is also a
> safe symlink - so a loop/recursion is needed. That said, using the new
> "is_ancestor_of" (from L::Util) is probably a lot easier to use
> correctly. Basically:
Thanks for the explanation and the example. I have updated my code and
the tests still work. Find the updated patches attached (rebased against
current master).
--
Best regards,
Michael
>From ceb4afecf02c6c1a1277ad69bb2d3430baed6fa9 Mon Sep 17 00:00:00 2001
From: Michael Stapelberg
Date: Sat, 13 Apr 2013 23:14:31 +0200
Subject: [PATCH 1/3] add systemd checks
---
checks/systemd | 252 +++
checks/systemd.desc | 76
2 files changed, 328 insertions(+)
create mode 100644 checks/systemd
create mode 100644 checks/systemd.desc
diff --git a/checks/systemd b/checks/systemd
new file mode 100644
index 000..866110c
--- /dev/null
+++ b/checks/systemd
@@ -0,0 +1,252 @@
+# systemd -- lintian check script -*- perl -*-
+#
+# Copyright © 2013 Michael Stapelberg
+#
+# based on the apache2 checks file by:
+# Copyright © 2012 Arno Töll
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, you can find it on the World Wide
+# Web at http://www.gnu.org/copyleft/gpl.html, or write to the Free
+# Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+# MA 02110-1301, USA.
+
+package Lintian::systemd;
+
+use strict;
+use warnings;
+
+use File::Basename;
+use Text::ParseWords qw(shellwords);
+
+use Lintian::Tags qw(tag);
+use Lintian::Util qw(fail);
+
+sub run {
+my ($pkg, $type, $info) = @_;
+
+# Figure out whether the maintainer of this package did any effort to
+# make the package work with systemd. If not, we will not warn in case
+# of an init script that has no systemd equivalent, for example.
+my $ships_systemd_file = (scalar ( grep { m,/systemd/, } $info->sorted_index ) > 0);
+
+# An array of names which are provided by the service files.
+# This includes Alias= directives, so after parsing
+# NetworkManager.service, it will contain NetworkManager and
+# network-manager.
+my @systemd_targets;
+
+for my $file ($info->sorted_index) {
+if ($file =~ m,^etc/tmpfiles\.d/.*\.conf$,) {
+tag 'systemd-tmpfiles.d-outside-usr-lib', $file;
+}
+if ($file =~ m,^etc/systemd/system/.*\.service$,) {
+tag 'systemd-service-file-outside-lib', $file;
+}
+if ($file =~ m,/systemd/system/.*\.service$,) {
+check_systemd_service_file ($pkg, $info, $file);
+for my $name (extract_service_file_names ($pkg, $info, $file)) {
+push @systemd_targets, $name;
+}
+}
+}
+
+my @init_scripts = grep { m,^etc/init\.d/.+, } $info->sorted_index;
+
+# Verify that each init script includes /lib/lsb/init-functions,
+# because that is where the systemd diversion happens.
+for my $init_script (@init_scripts) {
+check_init_script ($pkg, $info, $init_script);
+}
+
+@init_scripts = map { basename($_) } @init_scripts;
+
+if ($ships_systemd_file) {
+for my $init_script (@init_scripts) {
+tag 'systemd-no-service-for-init-script', $init_script
+unless grep /\Q$init_script\E\.service/, @systemd_targets;
+}
+}
+
+check_maintainer_scripts ($info);
+}
+
+sub check_init_script {
+my ($pkg, $info, $file) = @_;
+
+my $lsb_source_seen;
+my $path = $info->index ($file);
+unless ($path->is_regular_file ||
+($path->is_symlink && defined($path->link_resolved))) {
+tag 'init-script-is-not-a-file', $file;
+return;
+}
+open(my $fh, '<', $info->unpacked ($file))
+or fail "cannot open $file: $!";
+while (<$fh>) {
+s/^\s+//;
+next if /^#/;
+if (m,^(?:\.|source)\s+/lib/lsb/init-functions,) {
+$lsb_source_seen = 1;
+last;
+}
+}
+close($fh);
+
+if (!$lsb_source_seen) {
+tag 'init.d-script-does-not-source-init-functions', $file;
+}
+}
+
+sub check_system
Re: [RFR] Bits draft for Lintian 2.5.12
* Niels Thykier , 2013-04-17, 21:51: With that in mind, that would be something like: lintian (>= 2.5.12), lintian (<< 2.5.13~) If I am not mistaken. We should probably stress the need for "~" in the upper bound to avoid issues in stable backports. ACK, it's easy to forget about it. (I did it in lintian4python... /o\) -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130417195832.ga8...@jwilk.net
Re: [RFR] Bits draft for Lintian 2.5.12
On 2013-04-17 21:14, Jakub Wilk wrote: > * Niels Thykier , 2013-04-16, 22:06: >> API stability not included, so packages should add dependencies on >> Lintian accordingly. > > Well, adding dependencies would be required even if we guaranteed API > stability. :) Perhaps "dependencies" misses an adjective such as > "strict" or "tight"? > Indeed, going with "tight". > Anyway, how strict the dependency should be? > Is > lintian (>= 2.5.12), lintian (<< 2.5.13) > enough, or should I use: > lintian (>= 2.5.12), lintian (<< 2.5.12+) > ? That is indeed a good question. So far we appear to have been very conservative in "4 digit" releases (e.g. 2.5.10.X) in the few times they have been used[1]. They appear to only have been bug fix releases (not even introducing new tags). I would personally be fine with promising API stability for those releases for now. With that in mind, that would be something like: lintian (>= 2.5.12), lintian (<< 2.5.13~) If I am not mistaken. We should probably stress the need for "~" in the upper bound to avoid issues in stable backports. (Please see attached diff for the revised version) > >> * Reduce the constant overhead in invocating Lintian's collections. > > Typo: invocating -> invoking. > Thanks. ~Niels [1] Judging from the changelog there has only been one entry with that kind of versioning prior to 2.5.10.1. Anyhow. --- bits-orig 2013-04-17 21:47:27.503203010 +0200 +++ bits 2013-04-17 21:46:59.095929669 +0200 @@ -21,7 +21,13 @@ With Lintian 2.5.12 we have decided to open up for supporting for third-party checks. For more information see [LM#3.3] or the "API" docs[API-DOC]. API stability not included, so packages should add -dependencies on Lintian accordingly. +tight dependencies on Lintian accordingly. An example of such +dependency is: + + lintian (>= 2.5.12), lintian (<< 2.5.13~) + +Please be very careful to remember the "~" in the upper bound as +Lintian is regularly backported to stable. Since these checks are not restricted to all of the design choices of Lintian itself, so it is (among other things) possible to (ab)use the @@ -170,11 +176,11 @@ * Decompress gzip files via PerlIO gzip (when available) to reduce the number of external fork/exec calls. - - libperlio-gzip-perl (Available in Wheezy) + - Enable by installing libperlio-gzip-perl (Available in Wheezy) - This may vastly improve the runtime of Lintian on some non-Linux systems. - * Reduce the constant overhead in invocating Lintian's collections. + * Reduce the constant overhead in invoking Lintian's collections. - This overhead can be substantial for source packages that build many "small" binary packages. Examples include freebsd-utils @@ -184,7 +190,7 @@ Things we still have not been able to solve: * Lintian is still slow on packages with a lot of manpages. The root - cause is running man one each manpage, which is not optimized for + cause is running man on each manpage, which is not optimized for this use-case. - Symptom: checks/manpages is a bottleneck.
Re: [RFR] Bits draft for Lintian 2.5.12
* Niels Thykier , 2013-04-16, 22:06: API stability not included, so packages should add dependencies on Lintian accordingly. Well, adding dependencies would be required even if we guaranteed API stability. :) Perhaps "dependencies" misses an adjective such as "strict" or "tight"? Anyway, how strict the dependency should be? Is lintian (>= 2.5.12), lintian (<< 2.5.13) enough, or should I use: lintian (>= 2.5.12), lintian (<< 2.5.12+) ? * Reduce the constant overhead in invocating Lintian's collections. Typo: invocating -> invoking. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130417191413.ga3...@jwilk.net
