From mireille.louys at unistra.fr  Fri Jun  3 07:16:24 2011
From: mireille.louys at unistra.fr (Mireille Louys)
Date: Fri, 03 Jun 2011 16:16:24 +0200
Subject: Telecon on ObsCore DM and Proposed recommendation document
Message-ID: <4DE8ECB8.7000703@unistra.fr>

Hello:

After compiling your ansers , at http://doodle.com/xfmqvabv7qbkr2xi   it 
seems next Monday , June 6, is the most suitable  date.

Let us start at 18:00 european time ,  which is in Victoria 9:00 a:m for 
instance . Please check the time for your time zone .

I apoloqize for people not available on this day.
Minutes will be circulated.
The expected duration  should not be more than one hour.

Please call one of the following numbers and enter the participant's code.


    * If you are in North America: 1-604-899-2339
    * If you are outside North America: 1-403-232-0994
    * The participant's code is: 9641176#


Best wishes , Mireille

-- 
--------------------------------------------------------------
Mireille LOUYS          mailto: mireille.louys at unistra.fr

L S I I T&      CDS,
Ecole Nationale Superieure            Observatoire de Strasbourg
de Physique de Strasbourg,            11, Rue de l'Universite
Boulevard S?bastien Brant, BP 10413   67000 STRASBOURG
67412 ILLKIRCH Cedex       	      Tel: +33 3 68 85 24 34
---------------------------------------------------------------


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dal/attachments/20110603/bdb4e28a/attachment.html>

From mireille.louys at unistra.fr  Fri Jun  3 07:24:28 2011
From: mireille.louys at unistra.fr (Mireille Louys)
Date: Fri, 03 Jun 2011 16:24:28 +0200
Subject: preliminary agenda for Obscore telco : Monday 6
Message-ID: <4DE8EE9C.3060505@unistra.fr>

We plan to go through the last comments written on the RFC page.
Typos already identified are currently being corrected.

Main points to discuss:

collection_name and connections with telescope, instrument names
pol_states mandatory or not
document formating
section 5 : registering an Obstap service
any other document issue

Feel free to suggest some extra topic i may had forgotten.

Thanks ,
Mireille

-- 
--------------------------------------------------------------
Mireille LOUYS          mailto: mireille.louys at unistra.fr

L S I I T                       &     CDS,
Ecole Nationale Superieure            Observatoire de Strasbourg
de Physique de Strasbourg,            11, Rue de l'Universite
Boulevard S?bastien Brant, BP 10413   67000 STRASBOURG
67412 ILLKIRCH Cedex       	      Tel: +33 3 68 85 24 34
---------------------------------------------------------------



From m.b.taylor at bristol.ac.uk  Thu Jun 30 07:01:25 2011
From: m.b.taylor at bristol.ac.uk (Mark Taylor)
Date: Thu, 30 Jun 2011 15:01:25 +0100 (BST)
Subject: STILTS v2.3-1 released, including taplint
Message-ID: <alpine.LRH.2.00.1106301446450.18735@andromeda.star.bris.ac.uk>

Dear all,

There is a new release of STILTS, v2.3-1, available at the usual place:

   http://www.starlink.ac.uk/stilts/

The main new item in this release is the taplint command, which
is a test suite for TAP services.  This is not expected to be of
interest to most users, but those developing or running a TAP 
service might like to run it against their service to see what
issues are identified (hence the DAL list crosspost).

Documentation for taplint is at:

   http://www.starlink.ac.uk/stilts/sun256/taplint.html

and invocation having downloaded the jar file is as straightforward as:

   java -jar stilts.jar taplint <tap-service-url>

See the documentation for discussion of options to customise the
output or tests performed.

Taplint is not comprehensive and is somewhat experimental.  It is
possible that it reports some compliance errors for compliant services,
and it certainly does not test everything.  Although I don't have
an unlimited amount of time to work on it, I would be happy to 
work with TAP developers to fix errors or possibly improve or add
tests.  All feedback is in any case welcome.

A couple of bugfixes and minor functionality enhancements are also
included in this release, and there is an accompanying release 
of STIL (v3.0-2).

Mark

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/

From Thomas.A.McGlynn at nasa.gov  Thu Jun 30 13:35:08 2011
From: Thomas.A.McGlynn at nasa.gov (Tom McGlynn)
Date: Thu, 30 Jun 2011 16:35:08 -0400
Subject: TAP, automated site monitoring, and gzip encoding.
Message-ID: <4E0CDDFC.7050404@nasa.gov>

NASA sites are a prominent target for hackers and so Goddard uses 
automated tools that look for a variety of exploits including SQL 
injection attacks.  Currently TAP schema queries can trigger these. 
While our security folks don't want to be too specific as to what the 
triggers are I believe that the combination of:

    Support of arbitrary SQL in the query
    Lack of passwords
    Results that look like table schemas (because they are)
    Output in clear text

play a major role in making things look suspicious.  While they can 
turn off checking altogether that would mean that any real successful 
SQL injection attack could go undetected and we have lots of attempts 
every day.

One solution that I had hoped might work was to use a GZIP transfer 
encoding (or content encoding) for the query results.  Unfortunately 
it doesn't look like clients currently note the HTTP encoding headers.

NASA is probably a bit more paranoid about this than some, but I 
suspect that this will become a more common issue as time goes on.
Support for content or transfer encoding is an HTTP level issue so I 
don't think it requires any change to the TAP standard, just clients 
that look for the appropriate HTTP headers.  Would it be reasonable to 
request that clients support gzip encoding?  In addition to address 
this security issue I suspect this would generally substantially 
decrease the size of downloaded data and make our queries more responsive.

	Tom McGlynn



From seaman at noao.edu  Thu Jun 30 13:43:44 2011
From: seaman at noao.edu (Rob Seaman)
Date: Thu, 30 Jun 2011 13:43:44 -0700
Subject: TAP, automated site monitoring, and gzip encoding.
In-Reply-To: <4E0CDDFC.7050404@nasa.gov>
References: <4E0CDDFC.7050404@nasa.gov>
Message-ID: <3E29CA48-DE93-4F7A-BC41-465D61E66BC8@noao.edu>

Hi Tom,

You might also investigate:

	http://fits.gsfc.nasa.gov/tiletable.pdf

for this purpose.  FPACK already supports this option:

	http://heasarc.nasa.gov/fitsio/fpack/

"Paranoia" is a pretty good requirement to fold into data compression options :-)

Rob
---

On Jun 30, 2011, at 1:35 PM, Tom McGlynn wrote:

> NASA sites are a prominent target for hackers and so Goddard uses automated tools that look for a variety of exploits including SQL injection attacks.  Currently TAP schema queries can trigger these. While our security folks don't want to be too specific as to what the triggers are I believe that the combination of:
> 
>   Support of arbitrary SQL in the query
>   Lack of passwords
>   Results that look like table schemas (because they are)
>   Output in clear text
> 
> play a major role in making things look suspicious.  While they can turn off checking altogether that would mean that any real successful SQL injection attack could go undetected and we have lots of attempts every day.
> 
> One solution that I had hoped might work was to use a GZIP transfer encoding (or content encoding) for the query results.  Unfortunately it doesn't look like clients currently note the HTTP encoding headers.
> 
> NASA is probably a bit more paranoid about this than some, but I suspect that this will become a more common issue as time goes on.
> Support for content or transfer encoding is an HTTP level issue so I don't think it requires any change to the TAP standard, just clients that look for the appropriate HTTP headers.  Would it be reasonable to request that clients support gzip encoding?  In addition to address this security issue I suspect this would generally substantially decrease the size of downloaded data and make our queries more responsive.
> 
> 	Tom McGlynn
> 
> 


From paul.harrison at manchester.ac.uk  Thu Jun 30 14:25:23 2011
From: paul.harrison at manchester.ac.uk (Paul Harrison)
Date: Thu, 30 Jun 2011 22:25:23 +0100
Subject: TAP, automated site monitoring, and gzip encoding.
In-Reply-To: <4E0CDDFC.7050404@nasa.gov>
References: <4E0CDDFC.7050404@nasa.gov>
Message-ID: <042A3CD3-5D1E-4860-A012-87F550BA2E7F@manchester.ac.uk>


On 2011-06 -30, at 21:35, Tom McGlynn wrote:

> NASA sites are a prominent target for hackers and so Goddard uses automated tools that look for a variety of exploits including SQL injection attacks.  Currently TAP schema queries can trigger these. While our security folks don't want to be too specific as to what the triggers are I believe that the combination of:
> 
>   Support of arbitrary SQL in the query
>   Lack of passwords
>   Results that look like table schemas (because they are)
>   Output in clear text
> 
> play a major role in making things look suspicious.  While they can turn off checking altogether that would mean that any real successful SQL injection attack could go undetected and we have lots of attempts every day.
> 
> One solution that I had hoped might work was to use a GZIP transfer encoding (or content encoding) for the query results.  Unfortunately it doesn't look like clients currently note the HTTP encoding headers.
> 
> NASA is probably a bit more paranoid about this than some, but I suspect that this will become a more common issue as time goes on.
> Support for content or transfer encoding is an HTTP level issue so I don't think it requires any change to the TAP standard, just clients that look for the appropriate HTTP headers.  Would it be reasonable to request that clients support gzip encoding?  In addition to address this security issue I suspect this would generally substantially decrease the size of downloaded data and make our queries more responsive.
> 

Surely the appearance of SQL in the query is the what triggers the anti-hack filter - the results cannot be the cause as they are in VOTable and I would be very surprised if any anti-hacker tools know about VOTable....
So I bet looking for some form of encoding for the query would be more effective in this case - however if it was any sort of standard encoding then the anti-hacker tool ought to be decoding it anyway if it is any good, so I think that would not work either...

SQL injection attacks are a legitimate concern for the implementors of TAP servers too -  don't pass the query in a raw unparsed state straight to your database in your TAP server...So I think that the TAP server implementations have to be the guardians in this case and the general anti-hack tool turned off for the TAP servers...


Paul.