FreeTDS Development Group

[Marc Abramowitz <msabramo AT gmail.com>]

On Oct 9, 2013, at 7:34 PM, "James K. Lowden" <jklowden AT freetds.org> wrote:

> On Wed, 9 Oct 2013 17:22:02 -0700
> Marc Abramowitz <msabramo AT gmail.com> wrote:
>
>> I think the main thing is we have to rig up the FreeTDS unit tests so
>> that they can get the server credentials from environment variables
>> rather than the PWD file. This is so we can use built-in encryption
>> features of Travis CI to keep the credentials secret so they are not
>> abused.
>
> Hi Marc,
>
> As long as the credentials are passed in the clear, they're not
> secure.  Keeping them in the process's environment isn't much better.
> It might be better to publish the credentials and use permissioning on
> the server to ensure that the user can only run the unit tests.

Yes, a good point. I had been thinking of also encrypting the
connection to SQL Server -- either by using FreeTDS's support for
OpenSSL/GnuTLS or by connecting over an ssh tunnel or SSL tunnel like
stunnel (e.g.: http://www.freetds.org/userguide/stunnel.htm#E.G.ENCRYPTED).

I'm a little confused by what I've seen so far with trying to use a
FreeTDS compiled with GnuTLS and seeing "encryption = required" in the
freetds.conf -- it looks like it might be encrypting the login
packets, but then it sees something with an SSL self-signed
certificate and then the rest of the communication happens in the
clear. This might actually be okay for our purposes, if it is indeed
encrypting the login -- it's just bugging me that the connection won't
show as encrypted in sys.dm_exec_connections, so I don't know how I
can verify that communication between Travis CI and the SQL Server is
safe, since I don't think I can do packet sniffing on networks I don't
control. Anyway, that's kind of complicated, so I'll probably mention
that issue in more detail on another email thread. Perhaps it's a
misunderstanding and it can be cleared up and then SSL used.
Alternatively, stunnel would be another route to go.

Incidentally, if someone sniffs the credentials and gets access, it's
not the end of the world. It means they can get into an empty database
and mess up our tests. We'd reset the credentials and it would be
annoying but okay. I would prefer to encrypt the credentials so this
is next to impossible but even without encryption, I see it as pretty
unlikely and not horrible if it happens. I bet we can make encryption
work though and then it's a non-issue.

>> Then you or I would set up a GitHub mirror of Gitorious.
>
> That would be you.  ;-)

Done. https://github.com/FreeTDS/freetds

I made you and Freddy owners so you can do stuff with it if I get run
over by a bus.

Hopefully, folks don't start sending pull requests over there. I put
"PULL REQUESTS WILL BE IGNORED" in the description, because I don't
see a way to turn off PRs for a repository (I was able to turn off
issues).

This repo is syncing to Gitorious every 5 minutes via a cron job.

> I probably should point out there's nothing particularly rigorous about
> the tests.  The true rigorous testing is carried out every day by
> FreeTDS's thousands of users.

Good to know. Something is better than nothing. And maybe having the
tests more visible via a CI system will inspire people to add more to
them. Probably not, but who knows.

I just wrote a script that writes a PWD file from environment
variables -- https://gitorious.org/freetds/freetds/merge_requests/8

Marc
http://marc-abramowitz.com/