Re: Bug#943107: git-buildpackage to be autoremoved due to python2 transition

[Guido Günther]

Hi,
On Fri, Feb 28, 2020 at 01:27:46AM -0500, Boyuan Yang wrote:
> Hi all,
> 
> (dropping debian-release and debian-python since it's kind of irrelevant)
> 
> 在 2020-02-28五的 05:30 +0100，Johannes Schauer写道：
> > Quoting peter green (2020-02-27 22:54:19)
> > > > Relevant packages and bugs:
> > > >   943107 git-buildpackage: Python2 removal in sid/bullseye
> > > This bug is not marked as rc.
> > > 
> > > Nevertheless I believe that this bug report is in-fact a false positive.
> > > From
> > > what I can tell git-buildpackage, even in buster, does not (build-)depend
> > > on
> > > python 2 or any python 2 modules.
> > 
> > correct, but it does build-depend on packages that require python2: rpm
> > 
> > I was recently in a similar situation where I thought I had a false positive
> > for one of my package so I filed this bug:
> > 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952523
> > 
> > You can always check whether you got a false positive or not by investing
> > the
> > dependency relationship yourself. In this case:
> > 
> > dose-ceve -T grml --deb-builds-from --deb-native-arch=amd64 debsrc://Sources
> > deb://Packages > /tmp/graph.xml
> > botch-graph-shortest-path /tmp/graph.xml /tmp/out.xml --source
> > realpackage:src:git-buildpackage --target realpackage:src:python2.7
> 
> What I know currently:
> 
> 1. git-buildpackage build-depends on rpm 
> 2. src:rpm build-depends on python2, provides python-rpm
> 3. git-buildpackage has python-rpm in debian/tests/control
> 4. the only reverse-build-dependency for python-rpm is src:rpmlint
> 
> For 4), I just uploaded a NMU to migrate src:rpmlint from python2 to python3.
> For 3), I'm wondering if git-buildpackage maintainer will solve 3) so that
> src:rpm may stop shipping python-rpm and drop build-dependency on
> python2.

Thanks for the summary! I've dropped python2-rpm (which just sat
there from the python2 days) and switched from python-pydoctor to
pydoctor.
Cheers,
 -- Guido

> 
> -- 
> Thanks,
> Boyuan Yang

Re: Security. Allow to run only executables with certain hash

[Dmytro Spivak]

sorry, delete, please * after 1-hour living
password

2020-02-28 20:22 GMT+02:00, Dmytro Spivak :
> Please make a system app, that will prevent strange executables and
> wrappers to be launched.
>
> For developers:
>
> 1. this app must allow an execution only executables with certain
> hashes and deny execution of files, hashes of which are not prescribed
> in a control file.
>
> 2. the control file (of list of allowed executables and their hashes)
> and a configuration file of the app may be changed by 2 factor
> authentication (by sending an email with 8-digits 1-hour living
> password* (do not forget a delay of 5 seconds against guessing the
> password)) after a first configuration.
>
> 3. by installation of the app there must be a prompt to enter an email
> for 2 factor authentication process, email server settings for ability
> to send an email for 2 factor authentication.
>
> 4. for building a control file the app scans for all executables in
> the os, makes their (for example, sha1) hashes and writes full path
> and hash of each of them to the control file.
>
> 5. for stopping or killing the app must be the 2 factor authentication
> I suppose, too (or write the source code of /bin/kill binary so that
> if it is the app then nothing to do (pretermit action), but the
> original `/bin/kill` binary one can copy to a usb flash drive with a
> different name (for example, /media/ubuntu/usbflash/flwr) and if one
> needs to kill the app then he connects the usb flash and copies that
> binary /media/ubuntu/usbflash/flwr to the system and launches against
> the app (but for prevent a theft of /media/ubuntu/usbflash/flwr using
> for example, sh -c "while:; do sleep 10; inotifywait -rmq -e access
> /media/ubuntu/usbflash/ | while read line; do cp $line /path/to/;done;
> done" source code of /bin/cp or /bin/mv files can be written so that
> they can copy or move  /media/ubuntu/usbflash/flwr file only to
> special path on the system not to somewhere else)).
>

Security. Allow to run only executables with certain hash

[Dmytro Spivak]

Please make a system app, that will prevent strange executables and
wrappers to be launched.

For developers:

1. this app must allow an execution only executables with certain
hashes and deny execution of files, hashes of which are not prescribed
in a control file.

2. the control file (of list of allowed executables and their hashes)
and a configuration file of the app may be changed by 2 factor
authentication (by sending an email with 8-digits 1-hour living
password* (do not forget a delay of 5 seconds against guessing the
password)) after a first configuration.

3. by installation of the app there must be a prompt to enter an email
for 2 factor authentication process, email server settings for ability
to send an email for 2 factor authentication.

4. for building a control file the app scans for all executables in
the os, makes their (for example, sha1) hashes and writes full path
and hash of each of them to the control file.

5. for stopping or killing the app must be the 2 factor authentication
I suppose, too (or write the source code of /bin/kill binary so that
if it is the app then nothing to do (pretermit action), but the
original `/bin/kill` binary one can copy to a usb flash drive with a
different name (for example, /media/ubuntu/usbflash/flwr) and if one
needs to kill the app then he connects the usb flash and copies that
binary /media/ubuntu/usbflash/flwr to the system and launches against
the app (but for prevent a theft of /media/ubuntu/usbflash/flwr using
for example, sh -c "while:; do sleep 10; inotifywait -rmq -e access
/media/ubuntu/usbflash/ | while read line; do cp $line /path/to/;done;
done" source code of /bin/cp or /bin/mv files can be written so that
they can copy or move  /media/ubuntu/usbflash/flwr file only to
special path on the system not to somewhere else)).

Re: Security. Allow to run only executables with certain hash

[Steve Kemp]

Good luck finding somebody to write this for you.  If you're interested in
kernel security you might enjoy this module which makes it possible to do
most of what you want - but it'll require hacking:

https://github.com/skx/linux-security-modules/tree/master/security/can-exec

In general what you want is hard, you'll need to compromise (no pun
intended), or pay a lot of money to get it developed for you.

Steve

On Fri, Feb 28, 2020 at 8:42 PM Dmytro Spivak  wrote:

> sorry, delete, please * after 1-hour living
> password
>
> 2020-02-28 20:22 GMT+02:00, Dmytro Spivak :
> > Please make a system app, that will prevent strange executables and
> > wrappers to be launched.
> >
> > For developers:
> >
> > 1. this app must allow an execution only executables with certain
> > hashes and deny execution of files, hashes of which are not prescribed
> > in a control file.
> >
> > 2. the control file (of list of allowed executables and their hashes)
> > and a configuration file of the app may be changed by 2 factor
> > authentication (by sending an email with 8-digits 1-hour living
> > password* (do not forget a delay of 5 seconds against guessing the
> > password)) after a first configuration.
> >
> > 3. by installation of the app there must be a prompt to enter an email
> > for 2 factor authentication process, email server settings for ability
> > to send an email for 2 factor authentication.
> >
> > 4. for building a control file the app scans for all executables in
> > the os, makes their (for example, sha1) hashes and writes full path
> > and hash of each of them to the control file.
> >
> > 5. for stopping or killing the app must be the 2 factor authentication
> > I suppose, too (or write the source code of /bin/kill binary so that
> > if it is the app then nothing to do (pretermit action), but the
> > original `/bin/kill` binary one can copy to a usb flash drive with a
> > different name (for example, /media/ubuntu/usbflash/flwr) and if one
> > needs to kill the app then he connects the usb flash and copies that
> > binary /media/ubuntu/usbflash/flwr to the system and launches against
> > the app (but for prevent a theft of /media/ubuntu/usbflash/flwr using
> > for example, sh -c "while:; do sleep 10; inotifywait -rmq -e access
> > /media/ubuntu/usbflash/ | while read line; do cp $line /path/to/;done;
> > done" source code of /bin/cp or /bin/mv files can be written so that
> > they can copy or move  /media/ubuntu/usbflash/flwr file only to
> > special path on the system not to somewhere else)).
> >
>
>

Bug#952764: ITP: python-django-libsass -- django-compressor filter using libsass

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-django-libsass
  Version : 0.8
  Upstream Author : Matt Westcott 
* URL : https://github.com/torchbox/django-libsass/
* License : BSD-3-clause
  Programming Lang: Python
  Description : django-compressor filter using libsass

 A django-compressor filter to compile Sass files using libsass.  It builds on
 libsass-python to make @import paths aware of Django's staticfiles mechanism,
 and provides a filter module for django-compressor which uses the
 libsass-python API directly, avoiding the overheads of calling an external
 executable to do the compilation.

I do intend to maintain this package as part of DPMT.

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAl5ZaFgRHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90WqyTgf+MpKlYbBsY6wJe41VmqSLhhn5WIIPNB+d
jmq1si+HsnGSbdTVa6orfrhEGW8XeWYRpRc6K3prnJQgMeDaTMXrWou+1HrcQprp
fm+y2jy+xpwOaqaxZQNQo8Ei5W+Y8UGjhxRm1AEsLJkCLV4fpnO+hMivFnMLKDZ4
SLkAcw25c7Le0s5+As6FciPSb128Spwd9/vC11r/XWDsHNTuDkYDS62rkpA9oTx6
7e/Q4kvfbCtiswfSCz7E2dKdspPO7NjwYqp7udL/ho6JEMIgyTVqAdH8qs7xD5CS
lQOzCYiFKmClb3KkyNekr7b74QXLr3v523Abn8MIAssMGY9nBoFo5w==
=yHRq
-END PGP SIGNATURE-

Re: Re: Security. Allow to run only executables with certain hash

[Dmytro Spivak]

Thank you, Steve! It is not for me but for everybody for the common
good. I`ve made just an idea, somebody must make the result. For all
companies who uses Debian OS and their customers against data
(personal, banking) thefts, persecution of oppositions in countries,
elections interferenses, for making the democracy and the humans
prosperity.

2020-02-28 20:56 GMT+02:00, Steve Kemp :
> Good luck finding somebody to write this for you.  If you're interested in
> kernel security you might enjoy this module which makes it possible to do
> most of what you want - but it'll require hacking:
>
> https://github.com/skx/linux-security-modules/tree/master/security/can-exec
>
> In general what you want is hard, you'll need to compromise (no pun
> intended), or pay a lot of money to get it developed for you.
>
> Steve
>
> On Fri, Feb 28, 2020 at 8:42 PM Dmytro Spivak  wrote:
>
>> sorry, delete, please * after 1-hour living
>> password
>>
>> 2020-02-28 20:22 GMT+02:00, Dmytro Spivak :
>> > Please make a system app, that will prevent strange executables and
>> > wrappers to be launched.
>> >
>> > For developers:
>> >
>> > 1. this app must allow an execution only executables with certain
>> > hashes and deny execution of files, hashes of which are not prescribed
>> > in a control file.
>> >
>> > 2. the control file (of list of allowed executables and their hashes)
>> > and a configuration file of the app may be changed by 2 factor
>> > authentication (by sending an email with 8-digits 1-hour living
>> > password* (do not forget a delay of 5 seconds against guessing the
>> > password)) after a first configuration.
>> >
>> > 3. by installation of the app there must be a prompt to enter an email
>> > for 2 factor authentication process, email server settings for ability
>> > to send an email for 2 factor authentication.
>> >
>> > 4. for building a control file the app scans for all executables in
>> > the os, makes their (for example, sha1) hashes and writes full path
>> > and hash of each of them to the control file.
>> >
>> > 5. for stopping or killing the app must be the 2 factor authentication
>> > I suppose, too (or write the source code of /bin/kill binary so that
>> > if it is the app then nothing to do (pretermit action), but the
>> > original `/bin/kill` binary one can copy to a usb flash drive with a
>> > different name (for example, /media/ubuntu/usbflash/flwr) and if one
>> > needs to kill the app then he connects the usb flash and copies that
>> > binary /media/ubuntu/usbflash/flwr to the system and launches against
>> > the app (but for prevent a theft of /media/ubuntu/usbflash/flwr using
>> > for example, sh -c "while:; do sleep 10; inotifywait -rmq -e access
>> > /media/ubuntu/usbflash/ | while read line; do cp $line /path/to/;done;
>> > done" source code of /bin/cp or /bin/mv files can be written so that
>> > they can copy or move  /media/ubuntu/usbflash/flwr file only to
>> > special path on the system not to somewhere else)).
>> >
>>
>>
>

Re: Security. Allow to run only executables with certain hash

[Seth Arnold]

On Fri, Feb 28, 2020 at 08:22:58PM +0200, Dmytro Spivak wrote:
> Please make a system app, that will prevent strange executables and
> wrappers to be launched.

Hopefully this is helpful to you:

https://sourceforge.net/p/linux-ima/wiki/Home/

Thanks


signature.asc
Description: PGP signature

Re: Security. Allow to run only executables with certain hash

[Russ Allbery]

Dmytro Spivak  writes:

> Please make a system app, that will prevent strange executables and
> wrappers to be launched.

This is doable as an LSM for executables.  Pretty sure there's a working
version of this on Android that uses hashes stored with the file and
signed.  (I recall seeing something in LWN about it.)

However, a major challenge is interpreted languages.  Do you allow people
to run /usr/bin/perl or not?  Both answers imply a lot of difficult
problems.  Java, Python, Node, and anything else in that family have the
same issue.  You can otherwise set this up with a Linux distribution with
existing tools and maybe a few additions, but in practice you would have
to bless Perl and Python (at least), and then it's not clear if you're
getting enough security benefit.

-- 
Russ Allbery (r...@debian.org)  

Bug#952776: RFP: libprometheus-tiny-perl -- tiny module to export monitoring metrics for Prometheus

[Guillem Jover]

Package: wnpp
Severity: wishlist
Tags: patch

* Package name: libprometheus-tiny-perl
  Version : 0.004
  Upstream Author : Rob N ★ 
* URL : https://metacpan.org/release/Prometheus-Tiny
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : tiny module to export monitoring metrics for Prometheus

 Prometheus::Tiny is a minimal metrics client for the Prometheus time-series
 database, that can be used to instrument a service so that it can export
 monitoring metrics so that Prometheus compatible servers can collect them.
 .
 It does the following things differently to Net::Prometheus:
  * No setup. No need to pre-declare metrics to get something useful.
  * Labels are passed in a hash. Positional parameters get awkward.
  * No inbuilt collectors, PSGI apps, etc. Just the metrics.
  * No different metric types. You get what you ask for.


This package makes it easier to write Prometheus clients, that need to
get metrics from external sources, otherwise you need to create your
own derived types.

Attached a working and tested packaging, where only the ITP bug number
needs to be filled in the debian/changelog, and Uploader added assuming
the Perl team wants to take it. :)

Thanks,
Guillem


libprometheus-tiny-perl_0.004-1.debian.tar.xz
Description: application/xz