Re: [galaxy-dev] user password different type encoding
I thought this would be transparent to the users instead of forcing
to reset the password.
Two thoughts... but please consider that I might not know what I am
talking about, and that these might not be good ideas ...
(1) James' implementation supports two hashing schemes in the table.
Couldn't you add a third, which would apply PBKDF2 to the older SHA-1
values (instead of two the clear text)? This would allow you to
update the table to convert existing passwords to PBKDF2(SHA-1) and
immediately get the security upgrade I think you're after.
(2) Seems like you could automatically change the table entry to
PBKDF2 the next time the user logs in. E.g. in check password, if the
existing password is SHA-1, or PBKDF2(SHA-1), and the guess is
successful, use to guess to create PBKDF2(guess) replacement in the
table. Note that I don't know enough about galaxy to know if the
table could be altered at that point/environment.
Bob H
On May 6, 2013, at 11:17 AM, Vipin TS wrote:
Thanks James!
I have pulled the recent changes to my repository and this is
working fine. I have tested with creating a new user
and I tried to login with the recently created user and this works
fine at my end. The entry looks like as follows:
galaxy=# select username,email,password from galaxy_user where email
= 'c...@gmail.com';
username | email | password
--+
+
---
cbio | c...@gmail.com | PBKDF2$sha256$1$7CWpfEOjZ3xmRH6b
$ufFHb8Ax9GkVBGmnR5fq159NA3C4F6o0
This works fine.
With this new implementation, the new registration password hashes
are generated in PBKDF2. May be one can force
the existing users to reset the password, so that all users password
will be updated in the table. As you mentioned in the
previous mail, because of random salt generation in the password
hashing step, I don't think I can take all of the existing
user’s SHA-1 hashes, run them through the algorithm and replace them
with the updated hashes. I thought this would
be transparent to the users instead of forcing to reset the password.
any thoughts on this?
Thank you for timely help,
--Vipin
Rather than committing this directly I created the following pull
request:
https://bitbucket.org/galaxy/galaxy-central/pull-request/165/password-security-use-pbkdf2-scheme-with
It would be great if a couple of people could sign-off on it before
merging. I don't think I'm doing anything stupid, but a sanity check
is appreciated.
--
James Taylor, Assistant Professor, Biology/CS, Emory University
On Sun, May 5, 2013 at 12:12 PM, James Taylor
ja...@jamestaylor.org wrote:
Vipin, I think the main problem here is that you cannot treat PBKDF2
as a hash in this way. Every time you hash the same password you
get a
different result because you are generating a new random salt.
Instead, you need to decode the in database representation to
extract
the salt and then do a comparison on the hashed part.
I have this working in a backward compatible way, and I think it
is a
good idea so I will be committing it to central shortly.
--
James Taylor, Assistant Professor, Biology/CS, Emory University
On Thu, May 2, 2013 at 2:34 PM, Vipin TS vipin...@gmail.com wrote:
Thanks James, I have updated the password of one user in
galaxy_user table
with the new algorithm,
I also adjusted the function new_secure_hash in
/lib/galaxy/util/hash_util.py in such a way that it returns
the new hash instead of sha1. Now I tried to login, it fails to
get the
account, I think there is something going
wrong in the password hash comparison. Can you please assit here.
+++ b/lib/galaxy/util/hash_util.py Thu May 02 14:33:07 2013
-0400
@@ -25,13 +25,60 @@
Returns either a sha1 hash object (if called with no
arguments), or a
hexdigest of the sha1 hash of the argument `text_type`.
+import hashlib
+from os import urandom
+from base64 import b64encode, b64decode
+from itertools import izip
+from pbkdf2 import pbkdf2_bin
+
+SALT_LENGTH = 12
+KEY_LENGTH = 24
+HASH_FUNCTION = 'sha256'
+COST_FACTOR = 1
+
if text_type:
+#return sha1( text_type ).hexdigest()
+
+sec_hash_1 = sha1( text_type ).hexdigest()
+
+if isinstance(sec_hash_1, unicode):
+sec_hash_1 = sec_hash_1.encode('utf-8')
+salt = b64encode(urandom(SALT_LENGTH))
+
+return 'PBKDF2${0}${1}${2}${3}'.format(
+HASH_FUNCTION,
+COST_FACTOR,
+salt,
+b64encode(pbkdf2_bin(sec_hash_1, salt, COST_FACTOR,
KEY_LENGTH,
getattr(hashlib, HASH_FUNCTION
thanks, Vipin
That should be the only place, it is called from the some
methods of
the User model object. So you could modify it to always hash new
passwords in a different way,
Re: [galaxy-dev] lastz on local galaxy failing
Howdy, Andreas, Lastz memory requirements are dependent on the size of the input sequences (mainly on the size of reference sequence) and, to a lesser extent, the genome's repeat content. I'm a little confused/concerned by how this failure was indicated. When run from a console, if lastz has a memory allocation failure, a message is written to stderr (e.g. call to realloc failed to allocate 1,000,000,000 bytes) and the program exits to the shell with the status EXIT_FAILURE (an ISO C definition which I presume corresponds to a standard shell error code). Usually, if lastz isn't going to have enough memory, an allocation failure will occur early in the run as all the long term data structures are being built. This would normally be within the first five minutes. A later failure would (probably) mean that the long term structures were close to the memory limit and then alignments for one of the query sequences required enough additional memory to push us over the limit. I assume galaxy's Job did not produce output message must be based on a lack of any output to stdout. What is strange is that fact that it took 2 days to get this message. Lack of output to stdout suggests that the failure occurred before any queries were processed (strictly speaking, before any alignments were output). This should have occurred in the first few minutes of the run. Would it be possible for you to point me at the input sequences for this run, so that I can try running this via the console, and see if there's something happening in lastz that I don't understand? Bob H On Nov 26, 2012, at 3:35 AM, Andreas Kuntzagk wrote: Hi, I just noticed that this was another case of a tool that needs more then the 1GB memory that is default on our cluster. After adjusting the job_runner settings everything seems fine. regards, Andreas On 15.11.2012 09:08, Andreas Kuntzagk wrote: Hi, when I start a lastz job it submits a job to GridEngine. But this job seems to hang. The process running is python /data/galaxy/galaxy-dist/tools/sr_mapping/lastz_wrapper.py -- ref_source= ... This wrapper seems to not start a lastz but lastz is in the path. After 2 days then Galaxy shows Job did not produce output Here is the paster.log from the start of the job. galaxy.jobs DEBUG 2012-11-15 09:03:07,539 (254) Working directory for job is: /data/galaxy/galaxy-dist/database/job_working_directory/000/254 galaxy.jobs.handler DEBUG 2012-11-15 09:03:07,540 dispatching job 254 to drmaa runner galaxy.jobs.handler INFO 2012-11-15 09:03:07,688 (254) Job dispatched galaxy.tools DEBUG 2012-11-15 09:03:07,980 Building dependency shell command for dependency 'lastz' galaxy.tools WARNING 2012-11-15 09:03:07,981 Failed to resolve dependency on 'lastz', ignoring galaxy.jobs.runners.drmaa DEBUG 2012-11-15 09:03:08,669 (254) submitting file /data/galaxy/galaxy-dist/database/pbs/galaxy_254.sh galaxy.jobs.runners.drmaa DEBUG 2012-11-15 09:03:08,670 (254) command is: python /data/galaxy/galaxy-dist/tools/sr_mapping/lastz_wrapper.py -- ref_source=cached --source_select=pre_set --out_format=sam --input2=/data/galaxy/galaxy-dist/database/files/027/ dataset_27795.dat --input1=/data/galaxy/galaxy-dist/tool-data/shared/ucsc/hg18/seq/ hg18.2bit --ref_sequences=None --pre_set_options=yasra98 -- identity_min=0 --identity_max=100 --coverage=0 --output=/data/galaxy/galaxy-dist/database/job_working_directory/ 000/254/galaxy_dataset_27800.dat --unmask=yes --lastzSeqsFileDir=/data/galaxy/galaxy-dist/ tool-data; cd /data/galaxy/galaxy-dist; /data/galaxy/galaxy-dist/ set_metadata.sh ./database/files /data/galaxy/galaxy-dist/database/job_working_directory/000/254 . /data/galaxy/galaxy-dist/universe_wsgi.ini /data/galaxy/galaxy-dist/ database/tmp/tmpL4MMJV /data/galaxy/galaxy-dist/database/job_working_directory/000/254/ galaxy.json /data/galaxy/galaxy-dist/database/job_working_directory/000/254/ metadata_in_HistoryDatasetAssociation_288_9ynzEN,/data/galaxy/ galaxy-dist/database/job_working_directory/000/254/ metadata_kwds_HistoryDatasetAssociation_288_AEIseO,/data/galaxy/ galaxy-dist/database/job_working_directory/000/254/ metadata_out_HistoryDatasetAssociation_288_RhsufT,/data/galaxy/ galaxy-dist/database/job_working_directory/000/254/ metadata_results_HistoryDatasetAssociation_288_86DYsR,/data/galaxy/ galaxy-dist/database/job_working_directory/000/254/ galaxy_dataset_27800.dat,/data/galaxy/galaxy-dist/database/ job_working_directory/000/254/ metadata_override_HistoryDatasetAssociation_288_HMRNEG galaxy.jobs.runners.drmaa DEBUG 2012-11-15 09:03:08,676 run as user ['kuntzagk', '600'] galaxy.jobs DEBUG 2012-11-15 09:03:08,676 (254) Changing ownership of working directory with: /usr/bin/sudo -E scripts/external_chown_script.py /data/galaxy/galaxy-dist/database/job_working_directory/000/254 kuntzagk 600 galaxy.jobs.runners.drmaa DEBUG
Re: [galaxy-dev] multithreaded tools
Howdy, Andreas, The four processes started for a galaxy lastz job must involve post- processing the lastz output through some other shell tool. Lastz by itself doesn't support multiple threads or processes. Bob H On Nov 26, 2012, at 3:58 AM, Andreas Kuntzagk wrote: Hi, I'm wandering how galaxy supports tools that are multithreaded or multi-process. When working with lastz I noticed that it starts 4 parallel processes. Is that always so? Can this be adjusted? What other tools also are multi-process? regards, Andreas -- Andreas Kuntzagk SystemAdministrator Berlin Institute for Medical Systems Biology at the Max-Delbrueck-Center for Molecular Medicine Robert-Roessle-Str. 10, 13125 Berlin, Germany http://www.mdc-berlin.de/en/bimsb/BIMSB_groups/Dieterich ___ 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: http://lists.bx.psu.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: http://lists.bx.psu.edu/
Re: [galaxy-dev] Giardine et al Galaxy paper (2005)
And Galaxy had a predecessor called Gala, probably also implemented in perl. Belinda may also have published a paper about Gala. Bob H On Jun 12, 2012, at 8:36 AM, Hans-Rudolf Hotz wrote: Hi Peter Have a look at Anton's talk Introduction to Galaxy at last years GCC meeting: http://wiki.g2.bx.psu.edu/Events/GCC2011 The first few slides are talking about the history of Galaxy, eg: Galaxy as a single Perl script (!) Regards, Hans On 06/12/2012 01:28 PM, Peter van Heusden wrote: Hi everyone The Galaxy system as described in Belinda Giardine et al's 2005 Genome Research paper (Galaxy: A platform for interactive large-scale genome analysis) appears to be radically different from the current Galaxy, at least in its technical specification. The paper mentions a C core spoken to by a Perl-based web user interface (referred to as the History User Interface). The co-authors on the paper are, however, familiar names from the current Galaxy team. Was this paper describing something in the pre-history of current Galaxy (it sounds rather like the current History but without workflows and of course implemented on a different platform)? Peter ___ 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: http://lists.bx.psu.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: http://lists.bx.psu.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: http://lists.bx.psu.edu/
Re: [galaxy-dev] server error
Given the information supplied, I suggest a spatula. Many servers are quite adept with a spatula. Your results may vary. Bob H On May 9, 2012, at 4:43 PM, Ashley Tehranchi wrote: Hi, I have run into a server error, how can I fix it? Thanks, Ashley ___ 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: http://lists.bx.psu.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: http://lists.bx.psu.edu/
