Debian package security policies

[Esokrates]

Hi,

I am asking myself the following questions and am wondering if there is a 
policy covering the aspects:

* Are source packages of free software packages required to only contain 
source code without binaries (maybe with the exception of the linux kernel and 
its firmware blobs)?
* Inspired by the following: 
https://code.google.com/p/chromium/issues/detail?id=350913 I am asking myself 
if debian source packages are (required to be able to) build offline? Or could 
it be that a package pulls in binaries/(source code) as part of the build 
process?
Is Debian one of the "distributions having a strict "build from source" 
requirement. Packages are built in a restricted environment and are required 
to declare in some way what binaries they need to build. The network is not 
available"

This would be something I would really like to know, since it is of strong 
philosophical value for me. I have already read some policies of the debian 
project, but could not specifically find a section covering those aspects.
Considering reproducible builds becoming reality, that aspect is really one 
that is important for me.

Thanks very much!


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/2213774.hSPHtGL0S9@ubuntu

Re: Debian package security policies

[Paul Wise]

On Sun, Apr 5, 2015 at 6:20 PM, Esokrates wrote:

> * Are source packages of free software packages required to only contain
> source code without binaries (maybe with the exception of the linux kernel and
> its firmware blobs)?

Yes. The Debian version of the Linux kernel is also required to only
contain source code without binaries.

https://www.debian.org/social_contract#guidelines
https://www.debian.org/News/2010/20101215

> * Inspired by the following:
> https://code.google.com/p/chromium/issues/detail?id=350913 I am asking myself
> if debian source packages are (required to be able to) build offline? Or could
> it be that a package pulls in binaries/(source code) as part of the build
> process?
> Is Debian one of the "distributions having a strict "build from source"
> requirement. Packages are built in a restricted environment and are required
> to declare in some way what binaries they need to build. The network is not
> available"

Yes, Debian source packages are required to be able to build offline.
Not being able to do so would be an RC bug. I'm not sure if the
buildds enforce that yet though. Of course developer-built packages
might be built with online machines. pbuilder blocks network by
default, not sure about sbuild or qemubuilder though.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caktje6fen7vwpjk8mvvzlygrtckb_vtk_whj+1um-y_tb5e...@mail.gmail.com

Minified javascripts in packages

[Andreas Noteng]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I have a question regarding the use of minified javascripts in pacakges.
Of course these need to be accompanied by the proper source code, but
is it acceptable to simply use already minified js that often
accompany the source packages, as long as the source is also there?
Builing (at least in an automated manner) stuff like for instance
jQuery can be a pain in Debian since we do not have all the required
tools [1]. I agree that this approach is not ideal, but as long as we
don't have a working grunt i believe it is the most sensible approach.
We don't build the lib ourself, but it is possible to download the
source package and manually build if you're ok with installing
software that is not in Debian.

If we had multiple versions of the libs in Debian one could simply
remove the minified js from the source and use the one in Debian, but
at least in the case of jQuery the package in Debian is hopelessly
outdated because of [1]. I have experimented a bit with using the old
(pre grunt) build system for jQuery, and it seems to be possible, but
to spend hours doing this kind of build system reinvetion for every
lib upstream uses seems a bit silly to me.

Regards
Andreas Noteng


[1]: https://wiki.debian.org/Javascript/Nodejs/Tasks/grunt
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJVITFvAAoJELRG7qgympRaXXQQAKjP0TbJVANK+zGWDAGBM4aK
SiTFdiQCuD2elDf5o3yD02DXrvL1mdpS1psf+8KT+52hCAl0sagFauD9NJ2Uv6uy
me2RKznQC/1+pV1cO1LZBwMVggcb130Xhv6s468hVr/3Iqm3gdgG20HYbM7NNrme
QZKxdgEstjeQyKIAukPf3nPRtzSIGQ3VJ6H7HEEhfSxXteB825ZYqjfhLJOGVhok
RlpE6oWE4h8mb2N2ErqBkAqNR08BOkVXy+S2xNh6NnYVbc+ykIcEbRXUr5ueBTwi
gOvXoj5fYHBbo5htA5Xeaf8jqocWDQCDZtZw5zrqWOLskhi/cMwzcc0hOtLrcrnS
zBP7v+K392akI57fhvVu5TxYxtGwqkhG5rbyQqrLHMGLmUTypf6YcdAIrawRP4qY
kx0P1xJ+0bVlmj+iZipmFafxLqG28ECmvEjsaYPLuLO59+uddpLcW5uhC023HuzH
DLH6up/qnJ/1aIrCNx0fEEMiYBjy7kYXTKc9jRK/284lGZWitqjHmjM4Ry3bwCwg
Vio6T7stnYI2EeoXZ6DT99jjTNon5bWc1zqFy86lbaDFH10jBlKAk3haZZiRSsm+
meeiSaROpi2ZOBU/Mk6/OWJiNylKNVHDerW9lAiso8q4p9N3NW4g60erM7GveJrp
Nl0f+Cr4IGW6leyjNRsD
=vY95
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55213170.6010...@noteng.no

Re: Minified javascripts in packages

[Paul Wise]

On Sun, Apr 5, 2015 at 8:58 PM, Andreas Noteng wrote:

> I have a question regarding the use of minified javascripts in pacakges.
> Of course these need to be accompanied by the proper source code, but
> is it acceptable to simply use already minified js that often
> accompany the source packages, as long as the source is also there?

The best way to tell if the provided source is actually the source is
to build from source and compare the Debian and upstream build
artefacts. Also, security and QA folks would not be happy if they
patched the source to fix a bug and rebuilding the package did not
actually fix the problem due to the lack of building from source. That
said, the ftp-masters don't require actually building the source
during package build, just that it is possible to build from source
using only packages in Debian main.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caktje6g8hfhgbeaezwjkxrh5_xzvkrz_n5xrk6vmf-vyjga...@mail.gmail.com

Bug#781968: ITP: ioflo -- Automated reasoning engine and flow based programming python framework

[David Douard]

Package: wnpp
Severity: wishlist
Owner: David Douard 

* Package name: ioflo
  Version : 1.2.1
  Upstream Author : Samuel M. Smith 
* URL : http://www.ioflo.com
* License : Apache 2.0
  Programming Lang: Python
  Description : Automated reasoning engine and flow based programming 
python framework

IoFlo is a powerful open interoperable software python framework that enables 
non experts to intelligently automate their own programmable world. 

This is a requirement for the new raet (https://github.com/saltstack/raet)
transport layer that is optionnally proposed in salt. 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150405190407.11670.40544.report...@perseus.logilab.fr

Bug#781984: ITP: libnacl -- ctypes wrapper for libsodium

[David Douard]

Package: wnpp
Severity: wishlist
Owner: David Douard 

* Package name: libnacl
  Version : 1.4.2
  Upstream Author : Thomas S Hatch 
* URL : https://libnacl.readthedocs.org/
* License : Apache 2.0
  Programming Lang: Python
  Description : ctypes wrapper for libsodium

This library is used to gain direct access to the functions exposed by
Daniel J. Bernstein's nacl library via libsodium or tweetnacl. It has
been constructed to maintain extensive documentation on how to use nacl
as well as being completely portable.

This package is a dependency for raet, the new transport layer for salt.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150405201202.16891.80113.report...@perseus.logilab.fr

Re: Jessie Release Date: 2015-04-25

[Alexander Cherepanov]

On 2015-03-31 21:58, Niels Thykier wrote:

  * unfixed RC bugs in key packages, please see [1].



[1] 
https://udd.debian.org/bugs/?release=jessie_and_sid&merged=ign&keypackages=only&fnewerval=7&flastmodval=7&rc=1&ctags=1&cdeferred=1&sortby=id&sorto=asc&format=html#results


At the time of posting, there was a bug for unrar in this list. I think 
this one -- https://bugs.debian.org/774171 , it was fixed the next day.


Do I understand it right: a bug in a non-free package could be 
release-critical for Debian? I thought non-free area is not part of the 
Debian system...


--
Alexander Cherepanov


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5521a4d2.9040...@mccme.ru

Re: Jessie Release Date: 2015-04-25

[Russ Allbery]

Alexander Cherepanov  writes:

> At the time of posting, there was a bug for unrar in this list. I think
> this one -- https://bugs.debian.org/774171 , it was fixed the next day.

> Do I understand it right: a bug in a non-free package could be
> release-critical for Debian? I thought non-free area is not part of the
> Debian system...

It's RC for the package, but not for Debian.  In other words, if the bug
isn't fixed, the package would be pulled from the release, but it's pretty
unlikely that it would hold up the release itself.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87619aclu7@hope.eyrie.org

Re: Bug#781765: ITP: graph-tool -- Python library for network (graph) analysis

[Andreas Tille]

Hi,

On Fri, Apr 03, 2015 at 10:27:43AM +0200, Daniel Stender wrote:
> On 02.04.2015 23:43, Iain R. Learmonth wrote:
> > Hi,
> > 
> > On Thu, Apr 02, 2015 at 11:25:44PM +0200, Daniel Stender wrote:
>  * Package name: graph-tool
> >>> If it is a python library/module, should't it be in the python-
> >>> namespace ?
> >> Sorry, I've forgot to mention, the binary would be:
> >> python3-graph-tool.

Hmmm, this sounds unusual as well to me.  Could you please clarify
whether it is a python3 module or rater a user oriented application?  In
case of the later please stick to graph-tool as the binary name.  For
user applications it does not make any sense to add the programming
language to the package name.

> > The source package should still be python-graph-tool really. Unless
> > it's a standalone application on its own, it helps to keep things
> > tidy.
> 
> That's a point. All right.

Or you stick to your original source package name graph-tool which
sounds fine for an application package. 

As an additional hint:  The package sounds like interesting for the
Debian Science project.  Please check whether it might fit into one
or more tasks out of

http://blends.debian.org/science/tasks/

Kind regards

   Andreas.

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150406065532.gd29...@an3as.eu