News for hackers. Stuff that matters.

neuroid

I don't know anybody that would do a sequential scan over a file in production

Well, that's pretty much how one would try to crack a password using a wordlist.

EDIT: If the goal is to crack a bunch of properly hashed (PBKDF2, scrypt, etc.) and salted passwords then a lookup table is not very practical.

Re:Two New Satellites for Jupiter on Wednesday June 07, 2017 @07:40AM (#14505391)
There is another theory suggesting otherwise [1]:

Saturn’s mid-sized moons are like the monsters in late-night horror movies. Smash them into tiny pieces, and they glue themselves back together as new versions of the old moons. This new finding contradicts a theory that Saturn’s rings were caused by moons colliding.

[1]: https://www.newscientist.com/article/2132906-saturns-moons-c...

Re:Dockerizing MySQL at Uber Engineering on Monday November 28, 2016 @08:42AM (#13055313)
Screenshot from our management console.

This looks like an amazing tool.

Re:Lesser known Git commands on Friday September 30, 2016 @12:08PM (#12613304)
The first commit of a repository can not be rebased like regular commits

That's not necessarily true. This can be done with:

  git rebase -i --root
Re:LastPass autofill exploit on Wednesday July 27, 2016 @06:02PM (#12176840)
The issue mentioned in the blog post was fixed over a year ago [1]. However, the issue reported by Tavis Ormandy [2] is new.

[1]: https://blog.lastpass.com/2016/07/lastpass-security-updates....

[2]: https://bugs.chromium.org/p/project-zero/issues/detail?id=88...

Why should, say, pip packages have any problems with each other as long as they aren't imported directly in a python sourcefile.

Are you suggesting that package versions should be explicitly provided as part of import statements? Or that import statements should be mangled depending on the versions specified in setup.py?

Re:OpenTSDB RCE on Friday April 22, 2016 @09:15AM (#11548843)
Re:Magic is often used to describe confusing code on Friday March 25, 2016 @07:00PM (#11363383)
There is nothing magical about computing (unless you use Source Mage [1]). But, I have to agree with the author: people tend to use the word magic if they cannot immediately grasp the meaning of a piece of code. This code might use a language construct we are not familiar with, or implement a complex O(log N) algorithm, or it might use a magic number [2]. In most cases, however, it is worth to spend time to understand such code.

[1]: https://en.wikipedia.org/wiki/Source_Mage

[2]: https://en.wikipedia.org/wiki/Fast_inverse_square_root#Overv...

Re:Making large Python projects painless on Tuesday March 15, 2016 @10:33AM (#11289875)
Even though we had pinned all our dependencies (with requirements like package-x==1.2.3), pip would still reach out to PyPI before before deciding which version to pick.

Another solution for this would be to build wheels for all dependencies and invoke pip with --no-index -f https://url.to.wheels.

Re:Python Patterns (2013) on Tuesday March 08, 2016 @06:22AM (#11244658)
Just out of interest, what were the main challenges you faced when using Celery?

Celery is a task queue. Pika could definitely be used to build a task queue (similarly to how Celery is built on top of Kombu), but I can't think of many good reasons why that would pay off. Unless your use case was not a task queue...

Re:Microservices Ending Up as a Distributed Monolith on Friday March 04, 2016 @06:58AM (#11223191)
I had a quick look at the transcript of Ben's talk, and it seems that one of his main issues with microservices which share the same code base (and therefore dependencies) is the overhead of upgrading their dependencies. I do understand that in some cases this might be problematic. However, if the microservices are written using the same language (or runtime), there is a huge benefit of reusing some abstractions. These might include things like validation schemas, serialisation formats, etc. These are the things that most likely would need to be created anyway for every microservice written in a new language. As usual, there has to be some balance in the amount of coupling between microservices. But there is nothing inherently wrong with reusing code between them. I think the most important factor in a microservice ecosystem is having well defined protocols and APIs.
Re:A Better Pip Workflow on Wednesday March 02, 2016 @12:01PM (#11211182)
This. Using setup.py for specifying min versions (and occasionally max versions) is definitely the way to go.

However, manually maintaining a requirements file in addition to setup.py is quite tedious in the long run. It is much better to freeze requirements during the build process and use the generated requirements file for deployments. But, decent test coverage is key here.

Re:Ask HN: Who is hiring? (March 2016) on Tuesday March 01, 2016 @11:54AM (#11203993)
Paperless Receipts | http://ereceipts.co.uk | London, UK | Full Time | ONSITE

Our eReceipts platform enables retailers to capture vast quantities of transaction data and provides the insight to help them garner a deep understanding of their customers. We work with companies that include Argos, Halfords, Debenhams, Maplin and French Connection, among others. Our receipt count is currently at 236M and increases by roughly 3.7M receipts per week.

We are looking for a talented software engineer to help us expand our SaaS platform and introduce new and exciting features.

Most of our code base is written in Python, therefore strong Python skills are a must, but experience with Java, C#, and Lua would also be useful.

Our backend stack includes Pyramid, Celery, MySQL, MongoDB, InfluxDB and Elasticsearch, and is hosted at Rackspace on a number of Debian VMs. Our development process is built around Git, Review Board, Buildbot and a couple of thousand tests. We deploy with Ansible.

If you are interested, or have further questions, drop an e-mail to [email protected].