Re: Password Protecting GPG Keys

[Norbert Preining]

On Mon, 16 Jun 2014, Clint Byrum wrote:
> While they can try, they ultimately cannot get away with such illegal
> searches. The border is where our sovreignty begins and ends, not 100
> miles in:
> 
> http://scholar.google.com/scholar_case?case=6933260753627774699

This is a very different reading of yours ... and there are enough
cases - especially of digital equipment search - and this is what
we are discussing here, which were dismissed.

In the case you quote there was "no probable cause for the presence
of aliens". The judgement was mostly put upon this argument.

In case of digital equipment there is always a probability to have
something illegal in the eyes of the US, which means that the
the exception for Ammendment 4 will be granted, as seen 
in cases like Abidor vs Napolitano.

So while I consider it great that the judges in the case you mentioned
have decided in this way, I don't think this is the *norm* and
we - those travelling to the US - have to be aware of that.

Speak, disk image on secure server, entering with clean hd, fetching
hd image outside the 100mi border, etc etc ...

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13



-- 
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/20140617063417.gh6...@auth.logic.tuwien.ac.at

Re: Password Protecting GPG Keys

[Clint Byrum]

Excerpts from Norbert Preining's message of 2014-06-16 20:49:26 -0700:
> On Tue, 17 Jun 2014, Matthias Urlichs wrote:
> > > While that is sadly true, AFAIK all those legislations still require at
> > > least good cause, but more usually a court order, to do so.
> > > 
> > You have no legal protection whatsoever on the "international" side of many
> > countries' airports (sea ports, too, for that matter).
> 
> For that matter, in the US this zone stretches *100* miles into 
> the internal. In this area the US border police can search 
> each and everyone without warrant.
> 
> Counting the big cities in this stretch I would recommend *never*
> entering the US.

While they can try, they ultimately cannot get away with such illegal
searches. The border is where our sovreignty begins and ends, not 100
miles in:

http://scholar.google.com/scholar_case?case=6933260753627774699


-- 
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/1402982897-sup-5...@fewbar.com

Re: Password Protecting GPG Keys

[Norbert Preining]

On Tue, 17 Jun 2014, Matthias Urlichs wrote:
> > While that is sadly true, AFAIK all those legislations still require at
> > least good cause, but more usually a court order, to do so.
> > 
> You have no legal protection whatsoever on the "international" side of many
> countries' airports (sea ports, too, for that matter).

For that matter, in the US this zone stretches *100* miles into 
the internal. In this area the US border police can search 
each and everyone without warrant.

Counting the big cities in this stretch I would recommend *never*
entering the US.

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13



-- 
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/20140617034926.gg6...@auth.logic.tuwien.ac.at

Re: Password Protecting GPG Keys

[Matthias Urlichs]

Hi,

Christian Kastner:
> While that is sadly true, AFAIK all those legislations still require at
> least good cause, but more usually a court order, to do so.
> 
You have no legal protection whatsoever on the "international" side of many
countries' airports (sea ports, too, for that matter).
If a customs person tells you to either hand over your crypto keys or go
back home, you get to do exactly that.

-- 
-- Matthias Urlichs


-- 
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/20140617034526.ga10...@smurf.noris.de

Re: Password Protecting GPG Keys

[Russell Stuart]

On Mon, 2014-06-16 at 12:01 +, Thorsten Glaser wrote:
> You completely miss http://xkcd.com/538/ and the fact that some
> legislations may require you, with jail penalty, to hand over
> any encryption keys, passwords, etc. you have with you when
> inside their territory.

Quoting the man page:

"Following these instructions ensures your password is not the
weakest link in the chain. In reality this won't stop an attacker,
they will just move their attention to the next weakest link. Avoid
malware, dementia, rubber hoses, and the UK."

That aside, the rubber hose is mostly an orthogonal problem.  What you
are really trying to protect against isn't someone just stealing your
keys.  By itself it isn't sufficient to do real damage.  The attacker
needs something more: they have to steal your keys without you knowing.

This was demonstrated when a DD had to forfeit his laptop recently.  The
project found out almost immediately, and the loophole was closed before
it could be exploited.  The situation is similar if you have your credit
card details stolen, or banking credentials leaks, or you lose your
bitcoin wallet.  Once you find out about it the risk period ends.  Ergo
if you know about it immediately there is almost no risk, period.

So the rubber hose comic is funny, but is also misleading.  After all if
someone has hit you about the head with a rubber hose the odds are high
you will know he's done it.  But if someone gets hold of your encrypted
secret key and brute forces the password, you won't.  And if you don't,
you are looking at the possibility of someone install back doors into
Debian for years.  Yes, it is a black swan event - but they only need
one.

Unfortunately getting hold of the encrypted key is made easier because
because we have to back the damned things up.  If we do it properly, we
have created multiple copies, distributed them across separate
geographic localities, probably in different countries.

The only thing protecting those backups is the password.

If you have read this far, I hope you now understand what lead me to
think about the following scenario: let's assume the worst case
scenario: those backups are public.  Is it possible to securely protect
them using a human memorable password?


signature.asc
Description: This is a digitally signed message part

Re: HTTPS everywhere!

[Luca Filipozzi]

On Mon, Jun 16, 2014 at 07:54:40PM +0200, Christoph Anton Mitterer wrote:
> On Thu, 2014-06-12 at 20:16 +0200, Tollef Fog Heen wrote: 
> > > Supplying the Debian Root CA to people not using Debian could have been
> > > easily done by a *single* site that uses a cert available in all
> > > browsers... which offers the Debian Root CA for secure and "trusted"
> > > download.
> > 
> > That's a nice theory.  It does not align particularly well with what
> > happens in the real world.
> 
> Uhm... why not?
> 
> Anyway... it would be best if such Debian Root CA could be included in
> major other distros as well... so even if it's not installed by
> default... people from all distros would have an easy way to securely
> retrieve such root CAs, as long as they trust their own distro.

I think I'm a Good Person.  And I think that my fellow DSA team members are
also Good People.  And I think the SPI folks are Mostly Good People :) 

But I don't expect that to be anywhere close to sufficient for other distros to
include the Debian CA (by which you probably mean the SPI CA) into their
certificate stores.  I'd expect them to ask us to follow processes similar to
Mozilla's (https://wiki.mozilla.org/CA:How_to_apply).  It's not clear to me
that either SPI or Debian are prepared to do that.  Maybe we should go with
cacert.org... but they failed to step through the process and they're purpose
built for CA management.

From my perspective, HTTPS Everywhere and Archive Security are not the same.

I want to provide our end users, some of whom are not sufficiently technical to
decipher SSL warnings/errors with the opportunity to have secure communications
(to the extent that we can, anyway).  I rely on the GPG web of trust for
Archive Security.  If tools need to be improved, then that's where we (or
"them") should focus energies (and I seem to recall seeing an apt update,
recently).

Cheers,

Luca

-- 
Luca Filipozzi
http://www.crowdrise.com/SupportDebian


signature.asc
Description: Digital signature

Re: improving downloader packages (was: Re: holes in secure apt)

[Jakub Wilk]

* Christoph Anton Mitterer , 2014-06-16, 19:50:
Thomas mentioned that things would have been more secure if the buildds 
and e.g. pbuilder pulls in debian-keyring automatically and verify 
maintainer signatures.


debian-keyring is not useful for automatic authentication of source 
packages. The source package could have been signed years ago by a 
person who is no longer a DD. Or signed with a key that has been just 
replaced with another one. Or signed with a key that's not yet shipped 
in the package.


Incidentally, this is how I discovered this bug. A friend of mine (hi, 
Marcin!) wondered how he can authenticate a source package that was 
signed by a key that is not included in debian-keyring. I ensured him 
that there's nothing to worry about, as apt takes care of this, but he 
remained skeptical[0]. So I started playing with mitmproxy...



[0] And his skepticism was reinforced by (independent) discovery of this 
bug: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1098738


--
Jakub Wilk


--
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/20140616181439.ga...@jwilk.net

Re: sofftware outside Debian (Re: holes in secure apt)

[Christoph Anton Mitterer]

On Thu, 2014-06-12 at 23:06 +0200, Holger Levsen wrote: 
> both flashplugin-nonfree and torbrowser-launcher are (or will be) in contrib 
> (and thus not be part of Debian) for exactly those reasons you described.
Well I guess the reason for flash is rather the license, isn't it?

Anyway... just because something it in contrib/non-free for legal
reasons... I see no necessity to handle such packages less secure.
When we have things like susv[2,3,4]... we may not put them into main
normally packaged, but - being honest - many users won't simply care for
such license details... but what they want is, that they don't donwload
HTML documentation that contains javascript which sends all their data
to some attacker.


Cheers,
Chris. 


smime.p7s
Description: S/MIME cryptographic signature

Re: holes in secure apt

[Christoph Anton Mitterer]

On Thu, 2014-06-12 at 19:43 +0100, Wookey wrote: 
> So it does default to signed downloads and SFAIK will always do this
> wether or not any keys are installed/available, unless explicitly disabled.
What I meant was the discussion here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=432309

i.e. different behaviour depending on whether debian-archive-keyring is
installed or not.


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: HTTPS everywhere!

[Christoph Anton Mitterer]

On Thu, 2014-06-12 at 20:16 +0200, Tollef Fog Heen wrote: 
> > Supplying the Debian Root CA to people not using Debian could have been
> > easily done by a *single* site that uses a cert available in all
> > browsers... which offers the Debian Root CA for secure and "trusted"
> > download.
> 
> That's a nice theory.  It does not align particularly well with what
> happens in the real world.

Uhm... why not?

Anyway... it would be best if such Debian Root CA could be included in
major other distros as well... so even if it's not installed by
default... people from all distros would have an easy way to securely
retrieve such root CAs, as long as they trust their own distro.


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: improving downloader packages (was: Re: holes in secure apt)

[Christoph Anton Mitterer]

Hey Thijs.

On Thu, 2014-06-12 at 19:31 +0200, Thijs Kinkhorst wrote: 
> You raise a lot of broad concerns under the header "holes in secure apt" 
> which 
> I'm afraid does not much to get us closer to a more secure Debian.
Well I admit, that first this is just a lot of words... but I think
that's the first what would need to be done - i.e. agreeing on what we
actually want... and decisions here are probably more upon core Debian
developers (I mean those which are maintaining/developing) the affected
systems and have the necessary insight.

Secondly, given the nature of these issues - they are rather deeply in
the Debian core packages and core (i.e. the build system) - it's
probably not that easy for people other than those
maintainers/developers to really move something.


For example, Thomas mentioned that things would have been more secure if
the buildds and e.g. pbuilder pulls in debian-keyring automatically and
verify maintainer signatures.
So on suggestion of mine would have been: generally do that and only
allow tools like pbuilder not do to so, when some special flag is given.
But I'm far too less into the whole infrastructure so that I could now
whether it works out in practise.


> Not many 
> people will object that making Debian even more secure is a bad idea; it just 
> needs concrete action, not a large list of potential areas to work on.
Well I'd guess the later is the first step, isn't it?
Taking inventory:

- which tools do we have that obviously directly need secure APT to be
used
  - APT, aptitute, etc.
  - pbuilder, qemubuilder, piuparts, etc.
  - [c]debootstrap
  - git-buildpackage
  - libraries? python-debian and friends? (especially some
perl/python/php libaries seemed to never really verified any
certificates with SSL per default, until recently)

- which things can be used for high level attacks (downgrading, blocking
attacks), like apt-listbugs, apt-listchanges, debsecan,
debian-security-support, etc. (e.g. attacking a user by not showing him
that a critical bug has been found or fixed which the user must react
on)

- which tools that are probably not directly security critical use
APT/repo-related data in an unverified way
e.g. apt-file

- at which higher levels can we tighten security even more
E.g. currently Release files seem to have a rather large validity, for
example my current one:
> Date: Mon, 16 Jun 2014 09:03:47 UTC
> Valid-Until: Mon, 23 Jun 2014 09:03:47 UTC
Given that we often have very nasty zero-days,... these 7 days seem
pretty long to me.
Our security team is usually very fast and we have fixes often hours
after they're released... so these long validity times give an attacker
too many additional days.

- how may people use our tools in "invalid" ways
  - do all tools like apt give non-zero exit codes as soon as the
slightest hint for anything security problematic was found?
  - may people e.g. use the contents from /var/{lib|cache}/apt/ ,...
trusting that these are always valid, but they might not (possible
races?)

- which tools do we have that circumvent the package management system
(and/or the security team) altogether
(those downloader packages, Mozilla-stuff and other things that install
plugins from the web, tools like clamav, or rkhunter, that may download
stuff from the web)

- which services do we offer (alioth, or things like paste.debian.net)
that could may be used in a way relevant for security,... which are not
tightened up enough.
If e.g. the security team would share important fixes with the
maintainers via paste.d.n... but code could be forged during that steps
(and no, I don't trust any GANDI certs,... than it may be a simple but
effective attack.


> I suggest that you focus on one of those aspects of your email and take some 
> concrete action to get it addressed. For example this part:
Well the problem is,.. if we pick out one,... all other get forgotten...

And as you can imagine it's not up to me to decide any of these ideas...
and at best difficult to implement them alone.
Just take the IMHO too long expiry dates mentioned above... I can't just
decide this (it's probably the ftp masters who do that?)


> I think a better way than to create such a policy would be to create a simple 
> framework that does in-package downloading "right" and that downloader 
> packages can depend on and call from their scripts (a bit like dbconfig-
> common). An existing technical solution will probably be more quickly adopted 
> by the various packages than a set of requirements, and improvements need to 
> be made in only one place.
Well I think both would be needed...
a) clear policy which tells what are packages allowed to do and what not
For a package like torbrowser-launcher, verifying code just via the
upstream GPG keys is of course cheap (however, having the security
issues I've mentioned before), since if it would be done via hard coded
hashes, the debian package needs to update everytime a new upstream
version comes out.
Before it makes sense to wr

Re: Password Protecting GPG Keys

[Christian Kastner]

On 2014-06-16 14:01, Thorsten Glaser wrote:
> Russell Stuart  debian.org> writes:
> 
>> messages.  One of the reasons raised for not doing it is some felt
>> uncomfortable carrying around their GPG keys when travelling.
>>
>> My initial reaction was "that's being overly cautious" particularly
>> given there signing every message doesn't mean you have to carry around
>> your master key.  However, it did make me wonder just how safe a GPG key
>> (or indeed any file) is, if it is protected by a password and nothing
>> else.
> 
> You completely miss http://xkcd.com/538/

The $5 wrench people could also break into my apartment anytime they
wanted; that doesn't mean I don't lock the doors anyway.

When I take security precautions, I'm mostly thinking about the person
who might steal my laptop, or rob my apartment when I'm on vacation.
Those are very real threats and for data, they can be mitigated very
easily, to some extent. There is nothing irrational about that.

That comic is just a stab at *irrational* people. Like, people who
actually believe a government would build a multi-million-dollar
computer just to brute-force *their* keys.

> and the fact that some
> legislations may require you, with jail penalty, to hand over
> any encryption keys, passwords, etc. you have with you when
> inside their territory.

While that is sadly true, AFAIK all those legislations still require at
least good cause, but more usually a court order, to do so.

Christian


-- 
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/539f177d.1020...@kvr.at

Re: use of RDRAND in $random_library

[Russ Allbery]

Thorsten Glaser  writes:

> Your theory may be good, but we are talking about a scenario in which at
> least one of the other sources may be not just “shitty entropy” but “a
> bytestream specifically designed to counteract entropy in the output
> stream of the XOR” (independence is needed).

> You’d better use a mechanism that first hashes together the “untrusted”
> sources¹ and only combine that with the “a bit more trusted” entropy
> later, using appropriate algorithms.  Sure, XOR is fast, but arc4random
> on MirBSD performs pretty well too (I get about 40 MiB/s easily… on old
> Pentium-M hardware).

This is the reason why Fortuna uses SHA-256 to mix in entropy.  Provided
that you use a hash function to mix in entropy and that hash function
satisfies the requirements of a cryptographic hash function, there should
be no way for an attacker with control over an entropy source to reduce
the total entropy created by the the other entropy sources.  The worst
they should be able to do is add zero entropy.

Cryptography Engineering has an excellent chapter on pseudorandom number
generators that gets into the issues here.

-- 
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/87lhsw24su@windlord.stanford.edu

Bug#751785: ITP: haskell-shake -- build system library, like Make, but more accurate dependencies

[Colin Watson]

Package: wnpp
Severity: wishlist
Owner: Colin Watson 

* Package name: haskell-shake
  Version : 0.13.1
  Upstream Author : Neil Mitchell 
* URL : http://hackage.haskell.org/package/shake
* License : BSD-3-clause
  Programming Lang: Haskell
  Description : build system library, like Make, but more accurate 
dependencies

Shake is a Haskell library for writing build systems - designed as a
replacement for make.

To use Shake the user writes a Haskell program that imports
Development.Shake, defines some build rules, and calls the
Development.Shake.shakeArgs function. Thanks to do notation and infix
operators, a simple Shake build system is not too dissimilar from a
simple Makefile. However, as build systems get more complex, Shake is
able to take advantage of the excellent abstraction facilities offered
by Haskell and easily support much larger projects. The Shake library
provides all the standard features available in other build systems,
including automatic parallelism and minimal rebuilds. Shake also
provides more accurate dependency tracking, including seamless support
for generated files, and dependencies on system information (e.g.
compiler version). 


(This has been in the Haskell team's package plan for a while; I'm
packaging it now because the current version of haskell-hoogle became
unbuildable following the transition to haskell-conduit 1.1, and newer
upstream versions of haskell-hoogle require shake.)

-- 
Colin Watson   [cjwat...@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/20140616162235.ga30...@riva.ucam.org

Re: improving downloader packages (was: Re: holes in secure apt)

[Jonathan Dowland]

On Thu, Jun 12, 2014 at 07:31:14PM +0200, Thijs Kinkhorst wrote:
> I think a better way than to create such a policy would be to create a simple 
> framework that does in-package downloading "right" and that downloader 
> packages can depend on and call from their scripts (a bit like dbconfig-
> common). An existing technical solution will probably be more quickly adopted 
> by the various packages than a set of requirements, and improvements need to 
> be made in only one place.

This kind-of exists in "game-data-packager": except it isn't structured so that
you call it from another package. Instead, the 3rd party stuff to be packaged
are handled within gdp itself.

I wonder whether it would be possible to extend gdp to provide such a
framework, however I have a lot of reservations about the notion of running
download code in postinst stages etc. at all.

I once planned to rename gdp to just "data-packager", coinciding with the
first non-game thing to be supported. I idly considered the flash plugin
or Oracle's Java as such targets. But I never did it.


-- 
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/20140616123322.ga12...@bryant.redmars.org

Re: use of RDRAND in $random_library

[Thorsten Glaser]

Gunnar Wolf  gwolf.org> writes:

> using entropy to seed a PRNG, if you have several shitty entropy
> sources and one _really_ good one, and you xor them all together, the
> resulting output is as random as the best of them. If your hardware

Your theory may be good, but we are talking about a scenario in
which at least one of the other sources may be not just “shitty
entropy” but “a bytestream specifically designed to counteract
entropy in the output stream of the XOR” (independence is needed).

You’d better use a mechanism that first hashes together the
“untrusted” sources¹ and only combine that with the “a bit
more trusted” entropy later, using appropriate algorithms.
Sure, XOR is fast, but arc4random on MirBSD performs pretty
well too (I get about 40 MiB/s easily… on old Pentium-M hardware).

① MirBSD first accumulates them, using a hash that is almost²
  Bob Jenkins’ one-at-a-time hash (plus, thanks for tytso for
  pointing this out, some stirring) in an 128-byte buffer, no
  matter how fast they come in. Then, at most once a second,
  if the buffer has accumulated at least 128 bytes, this is
  mixed into an aRC4 structure which is never used directly
  (i.e. no costly “throw away initial keystream” and all that
  needed) but only used for contributing bytes to the “main”
  entropy pool (what is /dev/urandom in Linux) and the “real”
  aRC4 pool. (We don’t use XOR here either because we know
  they are not entirely independent… in fact we use this
  property to ensure some amount of stirring/mixing around.)

② It adds 1 in the initial step so that even adding a NUL byte
  to a 0x state contributes, and the finaliser step is
  replaced by AES’ MixColumn step, which is a bit slower, but
  has better mixing properties without losing anything from the
  original finalising step. Also, it is used during stirring the
  128-byte buffer.

bye,
//mirabilos


-- 
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/loom.20140616t140448-...@post.gmane.org

Re: Password Protecting GPG Keys

[Thorsten Glaser]

Russell Stuart  debian.org> writes:

> messages.  One of the reasons raised for not doing it is some felt
> uncomfortable carrying around their GPG keys when travelling.
> 
> My initial reaction was "that's being overly cautious" particularly
> given there signing every message doesn't mean you have to carry around
> your master key.  However, it did make me wonder just how safe a GPG key
> (or indeed any file) is, if it is protected by a password and nothing
> else.

You completely miss http://xkcd.com/538/ and the fact that some
legislations may require you, with jail penalty, to hand over
any encryption keys, passwords, etc. you have with you when
inside their territory.

Ugly, yes.

bye,
//mirabilos


-- 
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/loom.20140616t140025-...@post.gmane.org

Re: holes in secure apt

[Thorsten Glaser]

On Thu, 12 Jun 2014, David Kalnischkies wrote:

> For your attack to be (always) successful, you need a full-sources
> mirror on which you modify all tarballs, so that you can build a valid
> Sources file. You can't just build your attack tarball on demand as the

Erm, no? You can just cache a working Sources file and exchange
the paragraph you are interested in. That’s something that would
be easy in a CGI written in shell, *and* perform well. Trivial.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


--
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/alpine.deb.2.10.1406161203450.26...@tglase.lan.tarent.de

Bug#751734: ITP: r-cran-sendmailr -- send email using GNU R

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-sendmailr
  Version : 1.1-2
  Upstream Author : Olaf Mersmann 
* URL : http://cran.r-project.org/web/packages/sendmailR/
* License : GPL
  Programming Lang: R
  Description : send email using GNU R

 This GNU R package contains a simple SMTP client which provides a
 portable solution for sending email, including attachements, from within
 GNU R.


Remark: This package is part of the new chain of dependencies of some
BioConductor packages and will be maintained by the Debian Med at


 svn://anonscm.debian.org/debian-med/trunk/packages/R/r-cran-sendmailr/trunk/


-- 
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/20140616064803.9584.41834.report...@mail.an3as.eu