The implementation could be done by implementing the TLS configuration inside the SysLogHandler, or allowing the user to pre-configure the TLS socket by doing the wrapping themselves and only passing final the socket to SysLogHandler.
There are a couple of unmaintained pypi packages that tried to make a TLS syslog handler but don’t seem to have been maintained for a long time. For a feature like this, it makes sense to have it in core python rather than an unmaintained package.
Both of the handlers copy the SyslogHandler instead of subclassing it and are broken with pre 3.11 bugs (bug43196)
I think that TLS support is important enough that it can benefit people from having in the SysLogHandler, rather than everyone writing their own TLS wrapper. It also make’s sure that the code doesn’t rot and break with future changes to sysloghandler.
Passing in a socket isn’t the best option, I would rather follow the example of SMTPHandler and add parameters for a key pair.
Since it’s not entirely clear what the best approach is, I suggest you could create a package which implements a subclassed SysLogHandler and upload it on PyPI. Users that need it could install it, and you’ll get feedback that enables you to refine it. Once it’s reached a sufficient level of maturity, we could look at incorporating the by then tried-and-tested functionality into the stdlib.
OK, took a bit of time to figure out how pypi works and how to make a python package but I got there in the end.
So here’s a package which does the subclassing of SysLogHandler and does the TLS configuration for the user - tlssysloghandler · PyPI
I’ve tried to keep it simple in the number of new parameters being added. Most people will only ever want to use secure=True and use the default openssl system sycertificate store, but I’ve also allowed specifying custom cafile/cadata/etc. like the SMTPHandler does and if someone really wants can pass in an SSLContext or just do unverified TLS. I’m not too fond of the last two options, too much configurability breeds bad coding practices.
You may find it useful to announce the existence of the package on the mailing lists python-list@python.org and python-announce-list@python.org - it may reach a few more people. I don’t think this forum has a category for announcements of new packages.
Thanks a lot!
I’ve posted it to python-list and I tried to make an announcement on python-announce-list but it doesn’t show up, I assume it’s waiting for moderator approval.
I’m hoping to get this in core rather than maintain a package in PyPI
And I’d like to be sure that the functionality is properly tempered by real-world usage before considering adding it to the stdlib. Once added, it sort of becomes my responsibility, whereas the people who have contributed individual parts are free to move on …
It shouldn’t need much maintenance, unless people trying to use it run into problems, and then that need for maintenance might be reasonable.
There’s also the need to add tests (which might mean a partial implementation of a syslog daemon handling TLS) and documentation (both of which are missing from your PR - so I’ll close the PR now, but leave the issue open, if that’s OK).
I see there’s no source repository linked - that means one has to download the package to look through it. Would you consider changing that? Also, it’s not clear what the license is - the metadata visible on PyPI merely shows the start of the copyright statement. Consider using other metadata properties to make the license clearer to people browsing PyPI. It looks MIT-like, but I had to open up the downloaded archive to determine that.
