Re: [galaxy-dev] security: brute force login

[Martin Čech]

Amogelang:

Needless to say that you probably want to protect on your webserver side
(nginx is expected in the example by Dannon) as opposed to the Galaxy
application side.

If you are really serious about this you should probably ask in a different
place than here e.g. at http://security.stackexchange.com/ and research
other reputable sources as our experience with this would be limited.

Thanks for using Galaxy.

Martin

On Mon, Jan 4, 2016 at 2:16 PM Dannon Baker  wrote:

> Hi Amogelang,
>
> I'd recommend using a general purpose tool like fail2ban for this.  Here's
> a quick getting started guide that might help if you're using nginx:
> https://www.digitalocean.com/community/tutorials/how-to-protect-an-nginx-server-with-fail2ban-on-ubuntu-14-04
>
> -Dannon
>
> On Mon, Jan 4, 2016 at 2:13 PM, Raphenya, Amogelang 
> wrote:
>
>> Hi All,
>>
>> How can I prevent brute force login attack on the login page?
>>
>>
>>
>> ___
>> Please keep all replies on the list by using "reply all"
>> in your mail client.  To manage your subscriptions to this
>> and other Galaxy lists, please use the interface at:
>>   https://lists.galaxyproject.org/
>>
>> To search Galaxy mailing lists use the unified search at:
>>   http://galaxyproject.org/search/mailinglists/
>>
>
> ___
> Please keep all replies on the list by using "reply all"
> in your mail client.  To manage your subscriptions to this
> and other Galaxy lists, please use the interface at:
>   https://lists.galaxyproject.org/
>
> To search Galaxy mailing lists use the unified search at:
>   http://galaxyproject.org/search/mailinglists/
___
Please keep all replies on the list by using "reply all"
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
  https://lists.galaxyproject.org/

To search Galaxy mailing lists use the unified search at:
  http://galaxyproject.org/search/mailinglists/

Re: [galaxy-dev] security: brute force login

[Dannon Baker]

Hi Amogelang,

I'd recommend using a general purpose tool like fail2ban for this.  Here's
a quick getting started guide that might help if you're using nginx:
https://www.digitalocean.com/community/tutorials/how-to-protect-an-nginx-server-with-fail2ban-on-ubuntu-14-04

-Dannon

On Mon, Jan 4, 2016 at 2:13 PM, Raphenya, Amogelang 
wrote:

> Hi All,
>
> How can I prevent brute force login attack on the login page?
>
>
>
> ___
> Please keep all replies on the list by using "reply all"
> in your mail client.  To manage your subscriptions to this
> and other Galaxy lists, please use the interface at:
>   https://lists.galaxyproject.org/
>
> To search Galaxy mailing lists use the unified search at:
>   http://galaxyproject.org/search/mailinglists/
>
___
Please keep all replies on the list by using "reply all"
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
  https://lists.galaxyproject.org/

To search Galaxy mailing lists use the unified search at:
  http://galaxyproject.org/search/mailinglists/

Re: [galaxy-dev] security: brute force login

[Eric Rasche]

If you're using apache, mod_evasive is quite popular for this purpose.

On 01/04/2016 01:27 PM, Martin Čech wrote:
> Amogelang:
>
> Needless to say that you probably want to protect on your webserver
> side (nginx is expected in the example by Dannon) as opposed to the
> Galaxy application side.
>
> If you are really serious about this you should probably ask in a
> different place than here e.g.
> at http://security.stackexchange.com/ and research other reputable
> sources as our experience with this would be limited.
>
> Thanks for using Galaxy.
>
> Martin
>
> On Mon, Jan 4, 2016 at 2:16 PM Dannon Baker  > wrote:
>
> Hi Amogelang,
>
> I'd recommend using a general purpose tool like fail2ban for
> this.  Here's a quick getting started guide that might help if
> you're using
> nginx: 
> https://www.digitalocean.com/community/tutorials/how-to-protect-an-nginx-server-with-fail2ban-on-ubuntu-14-04
>
> -Dannon
>
> On Mon, Jan 4, 2016 at 2:13 PM, Raphenya, Amogelang
> > wrote:
>
> Hi All,
>
> How can I prevent brute force login attack on the login page?
>
>
>
> ___
> Please keep all replies on the list by using "reply all"
> in your mail client.  To manage your subscriptions to this
> and other Galaxy lists, please use the interface at:
>   https://lists.galaxyproject.org/
>
> To search Galaxy mailing lists use the unified search at:
>   http://galaxyproject.org/search/mailinglists/
>
>
> ___
> Please keep all replies on the list by using "reply all"
> in your mail client.  To manage your subscriptions to this
> and other Galaxy lists, please use the interface at:
>   https://lists.galaxyproject.org/
>
> To search Galaxy mailing lists use the unified search at:
>   http://galaxyproject.org/search/mailinglists/
>
>
>
> ___
> Please keep all replies on the list by using "reply all"
> in your mail client.  To manage your subscriptions to this
> and other Galaxy lists, please use the interface at:
>   https://lists.galaxyproject.org/
>
> To search Galaxy mailing lists use the unified search at:
>   http://galaxyproject.org/search/mailinglists/

-- 
Eric Rasche
Programmer II

Center for Phage Technology
Rm 312A, BioBio
Texas A University
College Station, TX 77843
404-692-2048
e...@tamu.edu

___
Please keep all replies on the list by using "reply all"
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
  https://lists.galaxyproject.org/

To search Galaxy mailing lists use the unified search at:
  http://galaxyproject.org/search/mailinglists/

[galaxy-dev] January 2016 Galactic News

[Dave Clements]

Hello all,

The *January 2016 Galactic News
* is hot off the
presses.

   -

   51 new publications, including 6 highlighted pubs
   
   -

   Event News 
   -

  *GCC2016 registration rates and training schedule
  
*
  -

  GCC2016 is seeking sponsors
  
  -

  Metagenomics Tools and Workflows Codefest Reports
  

  -

  All upcoming events
  
  -

   Who's Hiring
   
   -

   Two new public Galaxy servers
   

   -

   New Releases
   
   -

  Galaxy 15.10
  
  -

  galaxy-lib 16.1.0 - 16.1.7
  

  -

  CloudMan 15.12
  
  -

  Pulsar 0.6.0 - 0.6.1
  

  -

   ToolShed Contributions
   
from
   December
   -

   and some other news too
   .

Happy new year!

Dave Clements and the Galaxy Team


-- 
http://galaxyproject.org/
http://getgalaxy.org/
http://usegalaxy.org/
https://wiki.galaxyproject.org/
___
Please keep all replies on the list by using "reply all"
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
  https://lists.galaxyproject.org/

To search Galaxy mailing lists use the unified search at:
  http://galaxyproject.org/search/mailinglists/

[galaxy-dev] LDAP auth_conf.xml and search-filter condition

[Rémy Dernat]

Hi list,

I would like to enable a multiple search on (Open)LDAP to check if a user
is also a member of a specific "galaxy" group. I did not find anything
about this in the documentation.

Indeed, we do not want that all the LDAP users to be able to login to
galaxy and we do not want to change the LDAP structure because it is
already used by many applications.

I have a complex search-filter which is:
(((mail={email})(uid={username}))((cn=galaxy)(objectClass=posixGroup)(memberUid={username})))

However, this search filter gave me two answers. It is normal because I am
searching for the user, and then, if he belongs to a particular
(posix)group. So the bind failed (because it needs only one answer).

The basic one (to only bind) is working:
((mail={email})(uid={username}))

I also tried with 2 search-filter conditions but galaxy seems to keep only
the last one.

Is there any project to allow that in the (near) future versions (*) ? Or
is there any hidden xml tag (not in documentation) which can permit to
search the memberUid/memberOf value in LDAP ?

In the meantime we will change the default quota (like just some bytes) for
users to allow LDAP login (for all users already present in it).


Best,

Remy


(*) Alternatively, what code should I change in Galaxy ? I would be happy
to program it if I have enough time...
___
Please keep all replies on the list by using "reply all"
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
  https://lists.galaxyproject.org/

To search Galaxy mailing lists use the unified search at:
  http://galaxyproject.org/search/mailinglists/

Re: [galaxy-dev] This job is waiting to run - Issue after Update to 15.10

[John Chilton]

We have heard no other reports of this and I have not replicated it
locally, is it possible this was like a client-side caching error or
something that went away?

If not, can you retry updating to the latest commit of release_15.10 -
there have been a good number of bug fixes though I don't recall any
for this issue specifically.

-John


On Mon, Dec 21, 2015 at 7:03 AM, Matthias Enders
 wrote:
> After some trying a college figured out, the Tools are working just fine, but 
> all old datasets are not accessible by the tools via "redo the job". But I 
> can Download them and so on.
> ___
> Please keep all replies on the list by using "reply all"
> in your mail client.  To manage your subscriptions to this
> and other Galaxy lists, please use the interface at:
>   https://lists.galaxyproject.org/
>
> To search Galaxy mailing lists use the unified search at:
>   http://galaxyproject.org/search/mailinglists/
___
Please keep all replies on the list by using "reply all"
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
  https://lists.galaxyproject.org/

To search Galaxy mailing lists use the unified search at:
  http://galaxyproject.org/search/mailinglists/

Re: [galaxy-dev] RFC: new

[Eric Rasche]

Hi Peter,

On 01/02/2016 11:54 PM, Peter Cock wrote:
>
>
> On Friday, 1 January 2016, Björn Grüning  > wrote:
>
> Hi Galaxy developers,
>
> this is a RFC to get the implementation details right for a new action
> type in `tool_dependencies.xml`.
>
> Since years we try to save a very crucial sustainability problem:
>   **Non-sustainable links**!
>
>
> A little bit of history
> 
>
> At first we tried to [mirror
> tarballs](https://github.com/bgruening/download_store) with sceptical
> sustainability,
> like BioC or random FTP servers.
> But over time we encountered many more places which we can not trust.
> Google-Code, SourceForge etc ...
> We tried to mirror the entire BioC history by tracking the SVN history
> down and creating tarball for every revision ...  a Herculean task ...
> but still limited in scope because there are so many other things that
> needs to be archived to make Galaxy and all tools sustainable.
>
> In the end we ended up with the simplest solution, provide a community
> archive where everyone can drop tarballs that they want to be
> sustainable. The Galaxy Project was so generous and is funding the
> storage but we have plans to mirror and distribute the workload to
> universities and other institutes that want to help.
>
> The biggest problem we needed to solve was the access to the archive.
> Who can drop tarballs? How do we control access to prevent abuse
> of this
> system?
>
> We went ahead and the created the Cargo-Port:
> https://github.com/galaxyproject/cargo-port
> Access will be controlled by a community and via PR. Add your package
> and we will check the content (hopefully) automatically and the
> tarball
> will be mirrored to a storage server.
>
>
> RFC
> ---
>
> So far so good. This RFC is about the usage of Cargo-Port inside of
> Galaxy. I would like to propose a new action type that uses the
> Cargo-Port directly. It should replace ` sha256sum="6387238383883...">` and `` and
> offer a more transparent and user-friendly solution.
> The current state of the art is quite cumbersome since we need to
> generate manually the checksum, offer the correct link
> and get the same information into Cargo-Port. I would like to
> streamline
> this a little bit and use this as a good opportunity
> to fix and work on https://github.com/galaxyproject/galaxy/issues/896.
>
>
> Proposal ``:
>  * attribute for Id, Version, Platform, Architecture
>  * no URL, no checksum
>  * attribute for the URL to cargo-port/urls.tsv
>* default to the current github repo
>* configurable via galaxy.ini
>  * this action will more or less trigger this curl command: `$ curl
> https://raw.githubusercontent.com/galaxyproject/cargo-port/master/gsl.py
> | python - --package_id augustus_3_1`
>* which give us the freedom to change API, columns ... in
> Cargo-Port
> without updating Galaxy core
>* the only API that need to keep stable is `gsl`
>  * `gsl` will try to download from the original URL, specified in
> Cargo-Port. If this does not work we will download our archived one.
>  * Changing the current working dir? Is this what we want, e.g.
> automatically uncompress and change cwd like `download_by_url`.
>* We will need an attribute to not uncompress. A few tools need the
> tarballs uncompressed.
>
>
> Single Point of Failure - a small remark
> 
>
> Previously, Galaxy packages relied entirely on the kindness of
> upstream
> to maintain existing packages indefinitely. Obviously not a
> sustainable
> practice. Every time a tarball was moved, we had to hope one of us
> retained a copy so that we could ensure reproducibility. With the
> advent
> of the Cargo Port, we now maintain a complete, redundant copy of every
> upstream tarball used in IUC and devteam repositories, additionally
> adding sha256sums for every file to ensure download integrity. The
> community is welcome to request that files they use in their
> packages be
> added as well. We believe this will help combat the single point of
> failure by providing at least one level of duplication. The Cargo Port
> is considering plans to provide mirrors of itself to various
> universities and another layer of redundancy.
>
>
> Thanks for reading and we appreciate any comments.
>
> Eric, Nitesh & Bjoern
>
> -- https://gist.github.com/bgruening/48297c27cd72cbadea7a
>
>
> Maybe a question for Nitesh,
>
> Would this replace or coexist with related but narrower in scope
> Bioarchive project?
Different scope, coexist.

Bioarchive

  * Hosts only bioconductor packages
  * R package