Bug#933515: ITP: r-cran-tufte -- Tufte's Styles for R Markdown Documents

[Johannes 'josch' Schauer]

Package: wnpp
Severity: wishlist
Owner: Johannes 'josch' Schauer 

* Package name: r-cran-tufte
  Version : 0.5
  Upstream Author : Yihui Xie
* URL : https://cran.r-project.org/package=tufte
* License : MIT
  Programming Lang: GNU R
  Description : Tufte's Styles for R Markdown Documents

Provides R Markdown output formats to use Tufte styles for PDF and HTML output.
The Tufte handout style is a style that Edward Tufte uses in his books and
handouts. Tufte’s style is known for its extensive use of sidenotes, tight
integration of graphics with text, and well-set typography. This style has been
implemented in LaTeX and HTML/CSS, respectively.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-tufte

Re: default firewall utility changes for Debian 11 bullseye

[Aron Xu]

On Wed, Jul 31, 2019 at 12:27 PM Scott Kitterman  wrote:
>
> Please don't install one by default.  I suspect it will cause more trouble 
> for end users than it's worth.  Making sure our default install is severely 
> limited in what ports it listens to is likely more broadly useful and less 
> risky.
>

I agree, we should mitigate risks by keeping open ports as restricted
as possible by default. But it could be useful for higher level
tasksel tasks or meta packages to pull in a firewall configuration
utility (for instance, firewalld) for certain use cases, i.e. it could
be useful for a "standard" server installation with graphic desktop,
for which we could expect most users choosing this method would like
to have advanced firewalling as an enterprise feature to have
out-of-box.

Cheers,
Aron

P.S. I know there is no such a thing called "standard" installation in
Debian, but only referring the name for the sense of RHEL's default
installation entries.

Re: default firewall utility changes for Debian 11 bullseye

[Adam Borowski]

On Wed, Jul 31, 2019 at 04:27:24AM +, Scott Kitterman wrote:
> On July 30, 2019 11:52:30 AM UTC, Arturo Borrero Gonzalez  
> wrote:
> >On 7/16/19 11:07 AM, Arturo Borrero Gonzalez wrote:
> >> 2) introduce firewalld as the default firewalling wrapper in Debian,
> >> at least in desktop related tasksel tasks.
> >
> >There are some mixed feelings about this. However I couldn't find any
> >strong opinion against either.
> >
> >What I would do regarding this is (just a suggestion):
> >* raise priority of firewalld
> >* document in-wiki what defaults are, and how to move away from them
> >* include some documentation bits in other firewalling wrappers on how to
> >deal with this default, i.e what needs to be changed in the system for
> >ufw to work without interferences (disable firewalld?)
> >
> >I don't maintain/control firewalld/ufw so I can't do these changes myself
> >and will leave to Cyril/Michael/Jaime handle the situation for new
> >bullseye install as they see fit.
> 
> Please don't install one by default.  I suspect it will cause more trouble
> for end users than it's worth.  Making sure our default install is
> severely limited in what ports it listens to is likely more broadly useful
> and less risky.

+1000.

A network firewall is useful.  But why would someone want a _host_ firewall
for on any sane operating system?  If a daemon is not supposed to listen on
the network, don't install it or configure it that way.  If a process is
supposed to be contained and unable to use the network, contain it.

A port blocker just sabotages user's requests, requiring every configuration
action to be done twice.

An user who actually has a complex host setup needs basic skills to do so,
and those skills are more involved than installing a package would be.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian is one big family.  Including that weird uncle
⢿⡄⠘⠷⠚⠋⠀ and ultra-religious in-laws.
⠈⠳⣄

Re: default firewall utility changes for Debian 11 bullseye

[Scott Kitterman]

On July 30, 2019 11:52:30 AM UTC, Arturo Borrero Gonzalez  
wrote:
>Ok, after a couple of weeks, lets try to summarize:
>
>On 7/16/19 11:07 AM, Arturo Borrero Gonzalez wrote:
>> 
>> This email contains 2 changes/proposals for Debian 11 bullseye:
>> 
>> 1) switch priority values for iptables/nftables, i.e, make nftables
>Priority:
>> important and iptables Priority: optional
>> 
>
>Nobody seems to disagree with this point. So I will be doing this soon.
>
>> 2) introduce firewalld as the default firewalling wrapper in Debian,
>at least in
>> desktop related tasksel tasks.
>> 
>
>There are some mixed feelings about this. However I couldn't find any
>strong
>opinion against either.
>
>What I would do regarding this is (just a suggestion):
>* raise priority of firewalld
>* document in-wiki what defaults are, and how to move away from them
>* include some documentation bits in other firewalling wrappers on how
>to deal
>with this default, i.e what needs to be changed in the system for ufw
>to work
>without interferences (disable firewalld?)
>
>I don't maintain/control firewalld/ufw so I can't do these changes
>myself and
>will leave to Cyril/Michael/Jaime handle the situation for new bullseye
>install
>as they see fit.

Please don't install one by default.  I suspect it will cause more trouble for 
end users than it's worth.  Making sure our default install is severely limited 
in what ports it listens to is likely more broadly useful and less risky.

Scott K

Re: tag2upload (git-debpush) service architecture - draft

[Bastian Blank]

On Sun, Jul 28, 2019 at 07:05:49PM +0100, Rebecca N. Palmer wrote:
> That suggests that working towards requiring the SHA-256 mode of git (which
> at least sort of exists since 2.21 [2], but I don't know if it's usable yet)
> might be a better use of effort.

Please keep in mind that the archive needs to verify this.  How do you
intend to provide the required information within the existing source
package structure?

> [1] needs reproducibility, but simpler than pristine-tar in that we're only
> trying to create _a_ reproducible tarball (not match one created by
> upstream) and don't need to compress it (as it can be deleted after hashing
> - unfortunately tar doesn't obviously have a write-to-stdout option to allow
> tar | sha256).  Reproducible builds suggests tar --sort=name --owner=0
> --group=0 --numeric-owner.

For now "git archive" with tar output seems to reproducible from jessie
(2.1.4) to sid (2.23 rc).

Another idea, however we would need to trust some decompressors:

The hypothetical tool creates a complete .dsc file with the names and
checksums of the uncompressed files.  The user signed .dsc is put into
the tag.

The tag2upload service creates the .changes files with the names and
checksums of the compressed files.  It is then signed by the upload
tool.

Accepting a package with dak would looks more like this:
- Verify signature on .changes.
- Check for source-only (forced by the upload tool flag).
- Check checksums of included files.
- Verify signature of .dsc.
- Check ACL against user signature on .dsc.
- Decompress (this poses a DoS threat!).
- Check checksums of included decompressed files.
- Either:
  - accept compressed files as is.
  - re-compress (also DoS, due to large files), calculate new checksums,
accept.

Due to the implicit compression of files listed in .dsc, I would say
this is a new source format.

Regards,
Bastian

-- 
A little suffering is good for the soul.
-- Kirk, "The Corbomite Maneuver", stardate 1514.0

Re: Challenge from Julia's non-standard vendored openblas"64_"

[Mo Zhou]

Hi Benda,

On 2019-07-30 15:21, Benda Xu wrote:
> Does Julia's built-in package manager support to build packages from
> source, like R?  If so, the Debian version of Julia's package manager
> could be set to build from source by default.

My memory about Pkg.jl's behavior is fuzzy. At least currently I don't
know how to build e.g. Arpack.jl from source instead of using their
pre-built binaries.

Pkg.jl document mentioned nothing about prebuilt binaries:
https://docs.julialang.org/en/v1/stdlib/Pkg/

Re: Challenge from Julia's non-standard vendored openblas"64_"

[Benda Xu]

Hi Mo,

Mo Zhou  writes:

> 64-bit version without symbol mangling will run into problem as long
> as the user tries to install some fundamental .jl packages with the
> Julia's built-in package manager.

Does Julia's built-in package manager support to build packages from
source, like R?  If so, the Debian version of Julia's package manager
could be set to build from source by default.

Yours,
Benda

Re: default firewall utility changes for Debian 11 bullseye

[Stephan Seitz]

On Di, Jul 30, 2019 at 01:52:30 +0200, Arturo Borrero Gonzalez wrote:

Ok, after a couple of weeks, lets try to summarize:
1) switch priority values for iptables/nftables, i.e, make nftables 
   Priority: important and iptables Priority: optional

Nobody seems to disagree with this point. So I will be doing this soon.


I’ve migrated my iptables scripts to nft. In the end it was easier than 
expected, and everything is running fine.


What I’m missing:
There was an iptables addon for using geoip databases. This is missing.  
I found https://aur.archlinux.org/packages/nftables-geoip-db/

It is not part of Debian, but I managed to use it.

Shade and sweet water!

Stephan

--
| Stephan Seitz  E-Mail: s...@fsing.rootsland.net |
| If your life was a horse, you'd have to shoot it.   |

Re: default firewall utility changes for Debian 11 bullseye

[Arturo Borrero Gonzalez]

Ok, after a couple of weeks, lets try to summarize:

On 7/16/19 11:07 AM, Arturo Borrero Gonzalez wrote:
> 
> This email contains 2 changes/proposals for Debian 11 bullseye:
> 
> 1) switch priority values for iptables/nftables, i.e, make nftables Priority:
> important and iptables Priority: optional
> 

Nobody seems to disagree with this point. So I will be doing this soon.

> 2) introduce firewalld as the default firewalling wrapper in Debian, at least 
> in
> desktop related tasksel tasks.
> 

There are some mixed feelings about this. However I couldn't find any strong
opinion against either.

What I would do regarding this is (just a suggestion):
* raise priority of firewalld
* document in-wiki what defaults are, and how to move away from them
* include some documentation bits in other firewalling wrappers on how to deal
with this default, i.e what needs to be changed in the system for ufw to work
without interferences (disable firewalld?)

I don't maintain/control firewalld/ufw so I can't do these changes myself and
will leave to Cyril/Michael/Jaime handle the situation for new bullseye install
as they see fit.

Re: file(1) now with seccomp support enabled

[Colin Watson]

On Sat, Jul 27, 2019 at 03:55:36AM +0200, Christoph Biedl wrote:
> 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.

I ran into a ton of annoying problems like that when I added seccomp
filtering to man-db (the idea there being to limit what damage might be
done by potential bugs in groff and friends).  The worst difficulties
are from third-party programs that some people have installed: there are
a couple of apparently fairly popular Linux antivirus tools that work by
installing an LD_PRELOAD wrapper that talks to a private daemon using a
Unix-domain socket and/or a System V message queue; there's a VPN that
does something similar even though it really has no business existing at
this level or interfering with processes that have nothing to do with
networking; and there's the "snoopy" package in Debian that logs
messages to /dev/log on execve.

At the moment my compromise solution is to reluctantly open up the
minimum possible set of syscalls I could find that stopped people
sending me bug reports that were in fact caused by something injected
from outside my software, and to limit most of that to only those cases
where I've detected the relevant LD_PRELOAD wrappers as being present.

This is pretty unsatisfactory, but I haven't found a better alternative
("ignore the problem and tell users to uninstall the third-party
software in question after laboriously tracking down the exact cause of
the seccomp failure in each and every case" isn't a viable solution in
my mind).  I suppose I could interpose a wrapper executable where I've
forced ld.so into secure-execution mode somehow, but all the ways I know
of to do that involve conferring some additional privilege on it which
doesn't seem like the right way forward either.  Or maybe I could have a
wrapper executable and just unset LD_PRELOAD first.  All very annoying.

-- 
Colin Watson   [cjwat...@debian.org]

Re: file(1) now with seccomp support enabled

[Simon McVittie]

On Sat, 27 Jul 2019 at 10:01:41 +0200, Vincent Bernat wrote:
> Just a quick note: seccomp filters may need adaptations from one libc to
> another (and from one kernel to another as the libc may adapt to the
> current kernel). For example, with the introduction of "openat" syscall,
> the libc has started to use it for "open()" and the new syscall has to
> be whitelisted. On the other hand, if you start implementing seccomp
> filters late, you may have whitelisted only the "openat" syscall while
> older libc (or current libc running on older kernels) will invoke the
> "open" syscall.

Writing your whitelist in terms of groups of related syscalls collected
by some actively-maintained project, like the @basic-io, @ipc, etc. groups
understood by systemd's SystemCallFilter (see systemd.exec(5)), seems like
one way to mitigate this problem.

Another way to mitigate this is to split out the distrusted part of the
program into a helper subprocess that does as little I/O as possible,
and in particular sends input and output via pre-opened pipes or sockets
instead of opening things itself - after all, seccomp is named for
"secure computation", not "secure I/O" or "secure networking". However,
this is probably a lot easier to do for new code than as something that
can be retrofitted onto the assumptions of an existing codebase.

smcv

Re: Sorce only uploads with sbuild (was: Bits from the Release Team)

[Simon McVittie]

On Tue, 23 Jul 2019 at 18:22:58 +0200, Johannes Schauer wrote:
> Quoting Sean Whitton (2019-07-23 17:47:45)
> > ICBW but I am pretty sure that sbuild builds the source package *outside* of
> > the clean chroot.
> 
> that is correct. Indeed the source package is the way how the sources are
> copied into the chroot so sbuild cannot operate at all without having a source
> package first. And that source package is built *outside* the chroot.

Technically sbuild can also build source packages (with sbuild --source,
and optionally --no-arch-any --no-arch-all) - I use that in
, to make sure I get a pedantically
"clean" source package that is identical to what building in the target
distribution would have done. However, yes, that requires building
a temporary source package outside sbuild, and transferring that into the
build chroot in order to have sbuild rebuild it.

smcv

Bug#933390: ITP: python-ftputil -- high level library for python ftp

[olivier sallou]

Package: wnpp
Severity: wishlist
Owner: Olivier Sallou 
X-Debbugs-Cc: debian-devel@lists.debian.org,
python-modules-t...@lists.alioth.debian.org

* Package name: python-ftputil
  Version : 3.4
  Upstream Author : Stefan Schwarzer 
* URL : https://ftputil.sschwarzer.net/trac
* License : BSD
  Programming Lang: Python
  Description : high level library for python ftp

ftputil is a high-level FTP client library for the Python programming
language. ftputil implements a virtual file system for accessing FTP
servers, that is, it can generate file-like objects for remote files.
The library supports many functions similar to those in the os,
os.path and shutil modules. ftputil has convenience functions for
conditional uploads and downloads, and handles FTP clients and servers
in different timezones.

Needed by next release of biomaj package.
-- 

gpg key id: 4096R/326D8438  (keyring.debian.org)

Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438



-- 

gpg key id: 4096R/326D8438  (keyring.debian.org)

Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438