Bug#784788: rss2email: r2e-migrate forgets about email addresses
On Fri, May 08, 2015 at 09:54:38PM +0200, Yves-Alexis Perez wrote: > This is really painful, especially considering it's apparently not > possible to edit a feed afterwards. It looks like Etienne covered this issue already (thanks, Etienne :), but the way to edit feeds after ‘r2e add …’ is to just edit $XDG_CONFIG_HOME/rss2mail.cfg (e.g. ~/.config/rss2email.cfg). The INI-file-like syntax should be fairly accessible (and your newly-added feed should be at the bottom of the file). Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Bug#807748: rss2email: option to set user-agent
On Sat, Dec 12, 2015 at 11:57:43AM +0100, Samuele Battarra wrote: > some feeds start to apply filters on accepted user-agent, it could > be handy to have a way to set it to a custom value. Andrés floated code for this a while back [1], but it's tied up with some Maildir stuff. I'm still on the fence about the Maildir parts [2], but I've asked Andrés to reroll the user-agent code as a separate PR. Cheers, Trevor [1]: https://github.com/wking/rss2email/pull/32 [2]: https://github.com/wking/rss2email/pull/21 -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Bug#760963: rejects xml feed based on http server mie type
On Sun, Sep 28, 2014 at 10:10:22PM +0200, Etienne Millon wrote: > Here is the patch I applied and forwarded. Merged in a4b5ee45 (Merge branch 'content-type-warning', 2014-09-28), thanks :). signature.asc Description: OpenPGP digital signature
Bug#760963: rejects xml feed based on http server mie type
On Fri, Sep 26, 2014 at 05:58:01PM +0200, Etienne Millon wrote: > IMHO it's best to add an extra case to display a warning if exc is a > NonXMLContentType exception (like the case just above for > CharacterEncodingOverride), and to keep the existing behaviour (log > an error) for other exception classes, which will catch stuff like > #760078. > > I'll send you a patch if this sounds good to you. Sounds good to me, thanks :). Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Bug#760969: blows away file permissions on rss2email.cfg
On Tue, Sep 09, 2014 at 11:06:26AM -0400, Joey Hess wrote: > Each time it is used to update list of feeds, r2e rewrites > rss2email.cfg, and neglects to preserve its file permissions when > doing so. Hmm. It's possible we can use shutil.copy2 to seed the new versions [1]. The approach would be: * copy2 to create the new file, preserving as much metadata as possible * truncate the new file * fill it in with the new data * move it over the original file I'm also open to other approaches that still address atomic writes [2,3]. Cheers, Trevor [1]: https://docs.python.org/3/library/shutil.html#shutil.copy2 [2]: https://github.com/wking/rss2email/issues/22 [3]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=562547 -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Bug#760963: rejects xml feed based on http server mie type
On Tue, Sep 09, 2014 at 10:58:53AM -0400, Joey Hess wrote: > Perhaps if it's not a fatal problem it should not display as an > "error"? I problably should have done this a while ago. It's in master now [1]. Cheers, Trevor [1]: https://github.com/wking/rss2email/commit/e3a51b3cc6e7a99459ec7e968ec8b073a23a83f5 -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Bug#760963: rejects xml feed based on http server mie type
On Tue, Sep 09, 2014 at 09:13:57AM -0700, W. Trevor King wrote: > On Tue, Sep 09, 2014 at 10:58:53AM -0400, Joey Hess wrote: > > Perhaps if it's not a fatal problem it should not display as an > > "error"? > > I problably should have done this a while ago. It's in master now [1]. Actually, I'm going to claw that back, since we don't want things like #760078 slipping by as warnings. Maybe I should change 'processing error' to 'feedparser bozo'? Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Bug#760965: processing error: 'str' does not support the buffer interface:
On Tue, Sep 09, 2014 at 11:02:03AM -0400, Joey Hess wrote: > W. Trevor King wrote: > > Duplicate for #760078? > > In this case, the rss feed has items, but I am not getting any email > from rss2email for that feed. So not a duplicate, I think. #760078 is about a problem with feedparser for Python 3 and basic-auth URLs (so I still think this is a duplicate). I don't expect you to get any mail until you upgrade to a fixed feedparser. Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Bug#760965: processing error: 'str' does not support the buffer interface:
On Tue, Sep 09, 2014 at 10:45:17AM -0400, Joey Hess wrote: > joey@kite:~/.config>r2e add test http://test:t...@www.kitenet.net/index.rss > joey@kite:~/.config>r2e run test > processing error: 'str' does not support the buffer interface: test > (http://test:t...@www.kitenet.net/index.rss -> j...@kitenet.net) > > This is a valid feed, and while this particular example does not > use http basic auth, it fails the same when the username and passwrd are > actually required. Duplicate for #760078? Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Bug#760963: rejects xml feed based on http server mie type
On Tue, Sep 09, 2014 at 10:35:50AM -0400, Joey Hess wrote: > joey@kite:~>r2e add electoral-vote http://www.electoral-vote.com/index.rss > joey@kite:~>r2e run electoral-vote > processing error: application/octet-stream is not an XML media type: > electoral-vote (http://www.electoral-vote.com/index.rss -> j...@kitenet.net) “processing error”s are non-fatal warnings about bozo exceptions picked up by feedparser [1]. You should still get mail for entries in the poorly-served feed. If you *don't* get mail, that's because feedparser can't parse any entries, not because rss2email is being harsher than feedparser. Cheers, Trevor [1]: https://github.com/wking/rss2email/blob/v3.8/rss2email/feed.py#L427 -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Bug#760078: rss2email: No longer able to access password-protected feeds
On Mon, Sep 01, 2014 at 07:36:29PM -0400, Liam Morland wrote:
> lkmorlan@burns:~$ wget --user=lkmorlan --password='' -S
> '<...>/mediawiki/api.php?action=feedrecentchanges&feedformat=atom'
Ah, the MediaWiki URL was enough of a hint for me to reproduce this
with my Wikipedia account [1]. The problem is the following line in
Feedparser [2]:
auth = base64.standard_b64encode(user_passwd).strip()
which works in Feedparser's Python 2 but not in Python 3 (where
standard_b64encode expects a byte string [3]). I'm not sure what the
appropriate charset for the user information is [4,5], but I don't
have any non-ASCII in my Wikipedia credentials, so:
auth = base64.standard_b64encode(user_passwd.encode('ASCII')).strip()
worked for me. If you're using Debian's python3-feedparser, you'll
want to file a bug with them [6] (although Etienne maintains both
python3-feedparser and rss2email for Debian, so you may not actually
need to file a new bug ;).
Cheers,
Trevor
[1]:
https://:@en.wikipedia.org/w/api.php?action=feedrecentchanges&feedformat=atom
[2]:
http://code.google.com/p/feedparser/source/browse/feedparser/feedparser.py?name=v5.1.3#2994
[3]: https://docs.python.org/3/library/base64.html
[4]: http://tools.ietf.org/html/rfc3986#section-3.2.1
[5]: http://tools.ietf.org/html/rfc2617#section-2
[6]: https://packages.debian.org/sid/python/python3-feedparser
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
signature.asc
Description: OpenPGP digital signature
Bug#760197: rss2email: No warning when adding new feed with same name
On Mon, Sep 01, 2014 at 03:36:09PM -0400, Liam K Morland wrote: > lkmorlan:~$ r2e add example http://example.com/feed1 > lkmorlan:~$ r2e add example http://example.com/feed2 > lkmorlan:~$ r2e list > 1: [*] example (http://example.com/feed2 -> lkmorlan) > 2: [*] example (http://example.com/feed2 -> lkmorlan) Fixed with 3267f34 (feeds: Raise an exception when adding a feed with a duplicate name, 2014-09-01), which is part of the just-cut v3.9. Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Bug#760078: rss2email: No longer able to access password-protected feeds
On Mon, Sep 01, 2014 at 06:28:09PM -0400, Liam Morland wrote: > Commands using a valid feed with username and password in place of > "": > > lkmorlan@burns:~$ r2e new lkmorlan > lkmorlan@burns:~$ r2e add feed '' > lkmorlan@burns:~$ r2e -VVV run > … > process feed ( -> lkmorlan) > HTTP status 200 > could not get HTTP headers: feed ( -> lkmorlan) > unrecognized version: feed ( -> lkmorlan) > processing error: 'str' does not support the buffer interface: feed ( -> > lkmorlan) > … No headers? No recognized version? Are you sure this is a valid feed? Can you show us the headers you *are* getting? For example: $ wget -S http://blog.tremily.us/index.atom … HTTP request sent, awaiting response... HTTP/1.1 200 OK … Content-Type: application/atom+xml Content-Length: 59239 Last-Modified: Fri, 21 Feb 2014 21:53:59 GMT … Length: 59239 (58K) [application/atom+xml] Saving to: ‘index.atom’ $ head -n 5 index.atom http://www.w3.org/2005/Atom";> unfolding disasters http://blog.tremily.us//"/> Note that there have Feedparser-side encoding problems in the past, but newer versions of rss2email either work around them [1] or require post-5.1.3 versions of Feedparser [2]. Cheers, Trevor [1]: http://article.gmane.org/gmane.mail.rss2email/176 2d045d4 (feed: Disable feedparser's PREFERRED_XML_PARSERS, 2013-09-10, landed in 3.7). [2]: http://article.gmane.org/gmane.mail.rss2email/175 id:20130909183231.gh28...@odin.tremily.us -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Bug#760078: rss2email: No longer able to access password-protected feeds
On Mon, Sep 01, 2014 at 05:43:30PM -0400, Liam Morland wrote: > process example (http://user:passw...@example.com/feed -> lkmorlan) > HTTP status 200 > could not get HTTP headers: example (http://user:passw...@example.com/feed -> > lkmorlan) > unrecognized version: example (http://user:passw...@example.com/feed -> > lkmorlan) > processing error: 'str' does not support the buffer interface: example > (http://user:passw...@example.com/feed -> lkmorlan) Ah, that's because 'example.com/feed' isn't giving you an RSS or Atom feed ;). The ‘processing error’ reports are rss2email passing along a bozo exception [1]. If you can reproduce that error for a real feed (i.e. not ‘example.com’), you should probably report the problem to feedparser [2]. Cheers, Trevor [1]: https://github.com/wking/rss2email/blob/v3.8/rss2email/feed.py#L424 [2]: http://code.google.com/p/feedparser/ -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Bug#760078: rss2email: No longer able to access password-protected feeds
On Mon, Sep 01, 2014 at 03:18:44PM -0400, Liam Morland wrote: > I can add it, but it errors on run: > > lkmorlan@burns:~$ r2e add example http://user:passw...@example.com/feed > lkmorlan@burns:~$ r2e run > processing error: 'str' does not support the buffer interface: example > (http://user:passw...@example.com/feed -> lkmorlan) Hmm. Can you paste a traceback? Try: $ r2e -VVV run Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Bug#760078: rss2email: No longer able to access password-protected feeds
On Mon, Sep 01, 2014 at 06:14:46PM +0200, Etienne Millon wrote: > * Liam K Morland: > > r2e add http://user:passw...@example.com/feed > > > > Upon "r2e run", it gives a confusing error message if it has any > > such feeds in the database: > > > > processing error: 'str' does not support the buffer interface > > … (whatever is the cause, I agree that the cryptic error message is > a bug in itself). Strange. I get: $ r2e add http://user:passw...@example.com/feed usage: rss2email add [-h] name url [email] rss2email add: error: the following arguments are required: url Which seems pretty reasonable. Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Bug#742215: rss2email: invalid User-Agent
On Thu, Mar 20, 2014 at 09:00:20PM +0100, Jakub Wilk wrote:
> * W. Trevor King, 2014-03-20, 12:49:
> >We should be able to use:
> >
> > User-Agent: rss2email/3.8 (https://github.com/wking/rss2email)
> >
> >Does that sound legal to you?
>
> Yes, looks go to me. :-)
Fixed in master's ec438df (feed: Change _USER_AGENT from '+{url}' to
'({url})', 2014-03-20).
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
signature.asc
Description: OpenPGP digital signature
Bug#742215: rss2email: invalid User-Agent
On Thu, Mar 20, 2014 at 08:37:37PM +0100, Jakub Wilk wrote:
> User-Agent: rss2email/3.8 +https://github.com/wking/rss2email
>
> This is violation of RFC 2616 (HTTP/1.1), which defines the following
> syntax for the User-Agent field:
>
>User-Agent = "User-Agent" ":" 1*( product | comment )
>product = token ["/" product-version]
>product-version = token
>token = 1*
>separators = "(" | ")" | "<" | ">" | "@"
>| "," | ";" | ":" | "\" | <">
>| "/" | "[" | "]" | "?" | "="
>| "{" | "}" | SP | HT
>
> So the ":" and "/" characters are not allowed, except in comments.
Since:
comment= "(" *( ctext | quoted-pair | comment ) ")"
ctext =
We should be able to use:
User-Agent: rss2email/3.8 (https://github.com/wking/rss2email)
Does that sound legal to you?
signature.asc
Description: OpenPGP digital signature
Bug#740385: rss2email: can't set verbosity in rss2email.cfg
On Fri, Feb 28, 2014 at 10:40:06PM +0100, Jakub Wilk wrote: > I tried setting "verbose = debug" in the configuration file, but it > doesn't seem to have any effect. Yeah, that's not wired up yet. -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Bug#740384: rss2email: fails to raise NoToEmailAddress: TypeError: __init__() missing 1 required positional argument: 'feed'
On Fri, Feb 28, 2014 at 10:32:20PM +0100, Jakub Wilk wrote: > raise _error.NoToEmailAddress(feeds=feeds) > TypeError: __init__() missing 1 required positional argument: 'feed' Oops, thanks. Should be fixed in: git://github.com/wking/rss2email.git no-to-email-error with 763d9a8 (command: Set the 'feed' argument when raising NoToEmailAddress, 2014-02-28). signature.asc Description: OpenPGP digital signature
Bug#740383: rss2email: unhelpful "timeout exceeded" warnings
On Fri, Feb 28, 2014 at 10:00:23PM +0100, Jakub Wilk wrote: > This is not very helpful, because it doesn't say _which_ server > caused the problem. As I mentioned this morning on the mailing list [1], you can figure out which feed is involved by using '-VV'. A more elegant solution would be nice, but by the time we're building the error message, we've already deleted our reference to the function and data [2]. It shouldn't be too hard to save a message string with those parameters, but TimeLimitedFunction currently knows nothing about feed fetching, so any error message would be pretty generic. [1]: http://article.gmane.org/gmane.mail.rss2email/220 [2]: https://github.com/wking/rss2email/blob/v3.8/rss2email/util.py#L67 signature.asc Description: OpenPGP digital signature
Bug#740371: r2e-migrate: doesn't honour XDG_DATA_HOME: No such file or directory: '/home/jwilk/.local/share/rss2email.json'
On Fri, Feb 28, 2014 at 07:09:18PM +0100, Jakub Wilk wrote: > I don't have ~/.local/, because I have XDG_DATA_HOME set to something > else, and apparently r2e-migrate doesn't honour this variable. Rss2email itself currently has it's own XDG implementation, but there's also pyxdg [1] which provides some nice utility functions for this sort of thing. [1]: https://pypi.python.org/pypi/pyxdg signature.asc Description: OpenPGP digital signature
Bug#734327: rss2email "TypeError: sequence item 1: expected string or Unicode, NoneType found"
Jeroen, On Mon, Jan 06, 2014 at 12:43:53AM +0100, Jeroen Massar wrote: > Package: rss2email > Version: 1:2.71-2 I've picked up maintenance for rss2email [1], and started the 3.x series which is the basis of new Debian packages [2]. You might want to give that a spin and see if you can reproduce your error with the new code. Cheers, Trevor [1]: https://github.com/wking/rss2email [2]: http://packages.debian.org/experimental/rss2email -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Bug#446160: reopening 446160
On Fri, Sep 27, 2013 at 11:02:57AM +0200, Etienne Millon wrote:
> Additionally, starting from version 3.2, there is a "sendmail"
> configuration directive that you can set to "/usr/bin/esmtp" to do
> this without having to alias esmtp as the system-wide sendmail.
The configured 'sendmail' is invoked (in
rss2email.email.sendmail_send') as:
{configured-sendmail} -f {sender} {recipient} < {message}
If you don't use sendmail, but do use a drop in replacement, you just
configure the 'sendmail' setting to point to your replacement. If
your replacement doesn't support sendmail's usage syntax, you just
need to add a shim script to bridge the gap:
#!/bin/sh
SENDER=''
RECIPIENT=''
while [ "$#" -gt 0 ]; do
case "$1" in
'-f')
shift;
SENDER="$1"
;;
*)
RECIPIENT="$1"
break
;;
esac
shift
done
{your-mda} {your args, using $SENDER and $RECIPIENT as you see fit}
Due to the prevalance of the sendmail interface (sendmail, postfix,
esmtp, …), I imagine a shim like this would be useful for a number of
programs besides rss2email for anyone without any of the
sendmail-compatible mail handers installed.
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
signature.asc
Description: OpenPGP digital signature
Bug#723140: rss2email: Support paused feeds in r2e-migrate script
On Mon, Sep 16, 2013 at 09:28:19PM +0200, Denis Laxalde wrote: > def add(url): > return subprocess.call(['r2e', 'add', slugify(url), url]) > > +def pause(index): > +return subprocess.call(['r2e', 'pause', str(index)]) > > def main(): > if new_db_exists(): > @@ -88,10 +90,12 @@ def main(): > set_email(email) > > print 'Adding feeds:' > -for feed in feeds: > +for i, feed in enumerate(feeds): > url = feed.url > print url > add(url) > +if not feed.active: > +pause(i) I haven't used the conversion script myself, but if you're using slugify(url) to generate feed names in add(), I'd recommend using the same feed name (and not the feed index) for pausing: def pause(url): return subprocess.call(['r2e', 'pause', slugify(url)]) Then there is no need for enumerate(), and you don't run into errors if there are already feeds in the 3.x database when you run the conversion script (which would shift the index numbers). Feeds.index() allows you to index by name since ff650e8 (Cleanups to Feed and Feeds, 2012-10-04), which was well before 3.0. signature.asc Description: OpenPGP digital signature
Bug#694744: [Be-devel] Heavy documentation dependencies
On Fri, Nov 30, 2012 at 09:01:16AM +1100, Ben Finney wrote: > The Debian project still needs to keep its promise that the recipient can > modify any part of the package at the source level, and build it from the > modified source using only Debian. Fair enough. > That means the recipient of Debian must be able to build the documentation > from the reST files. And that means Debian needs to include the > dependencies for building the documentation, including required Docutils > extensions http://bugs.debian.org/559916>. > > So my advice to anyone who wants to work toward getting ‘bugs-everywhere’ > to enter Debian again is to work with the packagers of its build > dependencies, including getting Bug#559916 fixed. Unfortunately, #559916 has been open for almost three years now. There has even been an apparently ready-to-merge package since June (although the mentors link is out of date, the source is available [1]). I don't know what to do to push that forward (if anyone reading this knows what I can do, let me know. I'd be glad to help). What I *can* do is work on the BE side of things. My views on possible workarounds haven't changed much since the last time we discussed this: 1. Package BE without the docs (à la SciPy [2]) 2. Add a new build target to make the user-facing docs (doc/*.txt, which don't use numpydoc) without pulling in the API docs (doc/libbe/*, which does use numpydoc-style docstrings). Debian can package just the user-facing docs. 3. Build the docs without numpydoc A long time ago (on the BE list) you said: On Wed, Feb 23, 2011 at 05:19:42PM +1100, Ben Finney wrote: > "W. Trevor King" writes: > > All the user-directed stuff is fine. Some of the API documentation > > isn't quite as nice. > > You're right. I had assumed the dependency on the ‘numpydoc’ extension > was strict, but I'd be happy with those results. > > When I try today, though, I get this error: > > [snip error due to older Sphinx] Now that more modern versions of Sphinx have had time to percolate into Debian, would you care to revisit this? Cheers, Trevor [1]: http://anonscm.debian.org/viewvc/python-modules/packages/numpydoc/trunk/debian/ [2]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=600547 -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Bug#694744: [Be-devel] Debian packaging
On Thu, Nov 29, 2012 at 02:18:59PM -0500, W. Trevor King wrote: > I'll open a new package bug. Done: On Thu, Nov 29, 2012 at 07:33:04PM +, Debian Bug Tracking System wrote: > Thank you for filing a new Bug report with Debian. > ... > 694744: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=694744 -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Bug#694744: New upstream version 1.1.1
Package: bugs-everywhere Version: 0.0.193+bzr.r217-2 Severity: wishlist Tags: upstream Upstream (me) has released a new version [1]. The built HTML docs are in the distribution tarball, so the numpydoc dependency that sank 1.0.0 inclusion [2] should no longer be an issue. Cheers, Trevor [1]: http://bugseverywhere.org/ http://download.bugseverywhere.org/releases/be-1.1.1.tar.gz [2]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=609519 signature.asc Description: OpenPGP digital signature
Bug#662960: ssmpt doesn't validate server TLS certificates
Package: ssmtp
Version: 2.64-5
Severity: wishlist
Tags: patch
The current versions of sSMTP doesn't attempt to validate the server
certificate when using TLS. Without this, users authenticating over
encrypted connections might unknowingly be sending their
authentication information to a man in the middle.
The attached patch allows the user to configure a set of trusted
authorities which can be used to validate the server (`TLS_CA_File`
and `TLS_CA_Dir`). If neither configuration option is given, the
current behavious (no validation) is preserved.
The attached patch should be applied after my patch for bug #662959
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=662959).
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
From d4f02531856d842cea082cd22babe9cf7e78003e Mon Sep 17 00:00:00 2001
From: W. Trevor King
Date: Wed, 7 Mar 2012 10:12:43 -0500
Subject: [PATCH 3/3] Validate the server certificate when using TLS.
---
TLS |7 +--
ssmtp.c | 45 +
ssmtp.conf.5 |6 ++
3 files changed, 52 insertions(+), 6 deletions(-)
diff --git a/TLS b/TLS
index 74404a3..844bbd8 100644
--- a/TLS
+++ b/TLS
@@ -30,5 +30,8 @@ TLSKey=
Specify which key file should be used (can be the same as the
certificate file).
-TODO:
-* Check server certificate for changes and notify about it.
+TLS_CA_File=
+Optional file of trusted certificates for validating the server.
+
+TLS_CA_Dir=
+Optional directory of trusted certificates for validating the server.
diff --git a/ssmtp.c b/ssmtp.c
index c491cd4..85f5950 100644
--- a/ssmtp.c
+++ b/ssmtp.c
@@ -69,6 +69,8 @@ char *prog = (char)NULL;
char *root = NULL;
char *tls_cert = "/etc/ssl/certs/ssmtp.pem"; /* Default Certificate */
char *tls_key = "/etc/ssl/certs/ssmtp.pem";/* Default private key */
+char *tls_ca_file = NULL; /* Trusted Certificate file */
+char *tls_ca_dir = NULL; /* Trusted Certificate directory */
char *uad = (char)NULL;
char *config_file = (char)NULL;/* alternate configuration file
*/
@@ -1043,6 +1045,24 @@ bool_t read_config()
log_event(LOG_INFO, "Set
TLSKey=\"%s\"", tls_key);
}
}
+ else if(strcasecmp(p, "TLS_CA_File") == 0) {
+ if((tls_ca_file = strdup(q)) == (char *)NULL) {
+ die("parse_config() -- strdup()
failed");
+ }
+
+ if(log_level > 0) {
+ log_event(LOG_INFO, "Set
TLS_CA_File=\"%s\"\n", tls_ca_file);
+ }
+ }
+ else if(strcasecmp(p, "TLS_CA_Dir") == 0) {
+ if((tls_ca_dir = strdup(q)) == (char *)NULL) {
+ die("parse_config() -- strdup()
failed");
+ }
+
+ if(log_level > 0) {
+ log_event(LOG_INFO, "Set
TLS_CA_Dir=\"%s\"\n", tls_ca_dir);
+ }
+ }
#endif
/* Command-line overrides these */
else if(strcasecmp(p, "AuthUser") == 0 && !auth_user) {
@@ -1126,6 +1146,8 @@ int smtp_open(char *host, int port)
#ifdef HAVE_SSL
int err;
+ long lerr;
+ unsigned long ulerr;
char buf[(BUF_SZ + 1)];
/* Init SSL stuff */
@@ -1157,6 +1179,17 @@ int smtp_open(char *host, int port)
log_event(LOG_ERR, "Private key does not match the
certificate public key");
return(-1);
}
+
+ if (tls_ca_file || tls_ca_dir) {
+ if(!SSL_CTX_load_verify_locations(ctx, tls_ca_file,
tls_ca_dir)) {
+ ulerr = ERR_get_error();
+ log_event(LOG_ERR, "Error setting verify
location: %s",
+
ERR_reason_error_string(ulerr));
+ return(-1);
+ }
+ }
+
+ SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, NULL);
}
#endif
@@ -1261,14 +1294,20 @@ int smtp_open(char *host, int port)
ssl = SSL_new(ctx);
if(!ssl) {
- log_event(LOG_ERR, "SSL not working");
+ ulerr = ERR_get_error();
+ log_event(LOG_ERR, "SSL not working: %s",
+
Bug#662959: ssmpt uses unnecessary newlines in strings passed to log_event()
Package: ssmtp
Version: 2.64-5
Severity: wishlist
Tags: patch
The current versions of sSMTP often uses newlines in strings passed to
`log_event()`. This patch removes those newlines.
This patch should be applied after my patch for bug #662958
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=662958).
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
From 246ac1ca5e044547419d46c5c509a37b724484ef Mon Sep 17 00:00:00 2001
From: W. Trevor King
Date: Wed, 7 Mar 2012 09:09:51 -0500
Subject: [PATCH 2/3] Strings passed to `log_event()` do not need trailing
newlines.
---
ssmtp.c | 54 +++---
1 files changed, 27 insertions(+), 27 deletions(-)
diff --git a/ssmtp.c b/ssmtp.c
index 97d19dc..c491cd4 100644
--- a/ssmtp.c
+++ b/ssmtp.c
@@ -411,9 +411,9 @@ void revaliases(struct passwd *pw)
}
if(log_level > 0) {
- log_event(LOG_INFO, "Set
MailHub=\"%s\"\n", mailhost);
+ log_event(LOG_INFO, "Set
MailHub=\"%s\"", mailhost);
log_event(LOG_INFO,
- "via SMTP Port
Number=\"%d\"\n", port);
+ "via SMTP Port
Number=\"%d\"", port);
}
}
}
@@ -896,7 +896,7 @@ bool_t read_config()
}
if(log_level > 0) {
- log_event(LOG_INFO, "Set
Root=\"%s\"\n", root);
+ log_event(LOG_INFO, "Set Root=\"%s\"",
root);
}
}
else if(strcasecmp(p, "MailHub") == 0) {
@@ -910,8 +910,8 @@ bool_t read_config()
}
if(log_level > 0) {
- log_event(LOG_INFO, "Set
MailHub=\"%s\"\n", mailhost);
- log_event(LOG_INFO, "Set
RemotePort=\"%d\"\n", port);
+ log_event(LOG_INFO, "Set
MailHub=\"%s\"", mailhost);
+ log_event(LOG_INFO, "Set
RemotePort=\"%d\"", port);
}
}
else if(strcasecmp(p, "HostName") == 0) {
@@ -922,7 +922,7 @@ bool_t read_config()
}
if(log_level > 0) {
- log_event(LOG_INFO, "Set
HostName=\"%s\"\n", hostname);
+ log_event(LOG_INFO, "Set
HostName=\"%s\"", hostname);
}
}
else if(strcasecmp(p,"AddHeader") == 0) {
@@ -933,7 +933,7 @@ bool_t read_config()
die("cannot AddHeader");
}
if(log_level > 0 ) {
- log_event(LOG_INFO, "Set
AddHeader=\"%s\"\n", q);
+ log_event(LOG_INFO, "Set
AddHeader=\"%s\"", q);
}
}
#ifdef REWRITE_DOMAIN
@@ -942,9 +942,9 @@ bool_t read_config()
mail_domain = strdup(++p);
log_event(LOG_ERR,
- "Set RewriteDomain=\"%s\" is
invalid\n", q);
+ "Set RewriteDomain=\"%s\" is
invalid", q);
log_event(LOG_ERR,
- "Set RewriteDomain=\"%s\"
used\n", mail_domain);
+ "Set RewriteDomain=\"%s\"
used", mail_domain);
}
else {
mail_domain = strdup(q);
@@ -957,7 +957,7 @@ bool_t read_config()
if(log_level > 0) {
log_event(LOG_INFO,
- "Set RewriteDo
Bug#662958: ssmpt doesn't support separate client key/certificate files
Oops, here's the patch.
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
From eaec5d9c556f4752d52c42b6e025b5f4ee4c0343 Mon Sep 17 00:00:00 2001
From: W. Trevor King
Date: Wed, 7 Mar 2012 08:19:46 -0500
Subject: [PATCH 1/3] Add TLSKey option for separate key and certificate files.
---
TLS |6 +++---
ssmtp.c | 12 +++-
ssmtp.conf.5 |3 +++
3 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/TLS b/TLS
index ada03c5..74404a3 100644
--- a/TLS
+++ b/TLS
@@ -26,9 +26,9 @@ Set this to yes to make ssmtp identify itself with a
certificate.
TLSCert=
Specify which certificate file should be used.
+TLSKey=
+Specify which key file should be used (can be the same as the
+certificate file).
TODO:
* Check server certificate for changes and notify about it.
-* Diffrent Certificate and Key file?
-
-
diff --git a/ssmtp.c b/ssmtp.c
index af4d1e5..97d19dc 100644
--- a/ssmtp.c
+++ b/ssmtp.c
@@ -68,6 +68,7 @@ char *gecos;
char *prog = (char)NULL;
char *root = NULL;
char *tls_cert = "/etc/ssl/certs/ssmtp.pem"; /* Default Certificate */
+char *tls_key = "/etc/ssl/certs/ssmtp.pem";/* Default private key */
char *uad = (char)NULL;
char *config_file = (char)NULL;/* alternate configuration file
*/
@@ -1033,6 +1034,15 @@ bool_t read_config()
log_event(LOG_INFO, "Set
TLSCert=\"%s\"\n", tls_cert);
}
}
+ else if(strcasecmp(p, "TLSKey") == 0) {
+ if((tls_key = strdup(q)) == (char *)NULL) {
+ die("parse_config() -- strdup()
failed");
+ }
+
+ if(log_level > 0) {
+ log_event(LOG_INFO, "Set
TLSKey=\"%s\"\n", tls_key);
+ }
+ }
#endif
/* Command-line overrides these */
else if(strcasecmp(p, "AuthUser") == 0 && !auth_user) {
@@ -1138,7 +1148,7 @@ int smtp_open(char *host, int port)
return(-1);
}
- if(SSL_CTX_use_PrivateKey_file(ctx, tls_cert, SSL_FILETYPE_PEM)
<= 0) {
+ if(SSL_CTX_use_PrivateKey_file(ctx, tls_key, SSL_FILETYPE_PEM)
<= 0) {
perror("Use PrivateKey");
return(-1);
}
diff --git a/ssmtp.conf.5 b/ssmtp.conf.5
index 25f6ceb..d80a24a 100644
--- a/ssmtp.conf.5
+++ b/ssmtp.conf.5
@@ -54,6 +54,9 @@ See RFC 2487.
.It Cm TLSCert
The file name of an RSA certificate to use for TLS, if required.
.Pp
+.It Cm TLSKey
+The file name of an RSA key to use for TLS, if required.
+.Pp
.It Cm AuthUser
The user name to use for SMTP AUTH.
The default is blank, in which case SMTP AUTH is not used.
--
1.7.3.4
signature.asc
Description: OpenPGP digital signature
Bug#662958: ssmpt doesn't support separate client key/certificate files
Package: ssmtp Version: 2.64-5 Severity: wishlist Tags: patch The current versions of sSMTP require the client key and certificate in a single file (`TLSCert`) if you're authenticating your client using TLS. Often, keys (secret) and certificates (public) are stored in separate files. The ability to use separate files was listed as one of the TODO options in the `TLS` readme. I wanted the functionality, so I've implemented it via a new `TLSKey` option. I'm attaching a patch against the current head of git://git.debian.org/ssmtp/ssmtp.git Strangely, this repository seems to be at 2.64-5, while the package itself has moved on to 2.64-6. Is there another repository against which I should be constructing patches? Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Bug#579361: don't insert spurious blank lines
On 30-Apr-2010, Ben Finney wrote: > AFAIK. It might merely be sloppy coding, but I don't know. This was discussed on the BE list back when I was comming aboard in Nov 2008 [1]. It is, actually, intentional, although I'm not sure if it actually helps. The orginial mapfile formats included separating blank lines with a `context` argument that set the number of blank lines [2]. The idea was that if you placed enough blank space around each setting, even dumb merge algorithms would realize that they should treat each setting individually when merging, and not bother the user with resolving false conflicts if a bug had been modified in different branches. When the on-disk mapfile format moved to YAML [3], I kept a blank line after each entry for good luck. I don't think much effort has gone into testing the merge-scenario this was designed to assist with, but that's the idea. Perhaps we could make it a repository-wide option? Cheers, Trevor [1]: See Aaron Bentley's comments in [Be-devel] Re: set-root in git repository fails Fri Nov 14 02:41:11 GMT 2008 Message-id: <491ce547.8020...@aaronbentley.com> http://void.printf.net/pipermail/be-devel/2008-November/63.html [2]: See libbe/mapfiles in the following March 2005 revisions: a23c9c6cfbcc2bc77e6723edc4e059bca82fa924 ae298bfe570ebe7f1bf184e3f58e17613f3962fb [3]: See libbe/mapfiles in the December 2008 revision: 83e320a61eb74dab6eddfdda010f34fa42eedc0c -- This email may be signed or encrypted with GPG (http://www.gnupg.org). The GPG signature (if present) will be attached as 'signature.asc'. For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy My public key is at http://www.physics.drexel.edu/~wking/pubkey.txt pgpwbNUXbBk3Y.pgp Description: PGP signature
