Profile cover photo
Profile photo
Viacheslav Ivanov
87 followers -
Help will always be given at Hogwarts to those who ask for it.
Help will always be given at Hogwarts to those who ask for it.

87 followers
About
Posts

Post has shared content
I thought I'd write an update on git and SHA1, since the SHA1 collision attack was so prominently in the news.

Quick overview first, with more in-depth explanation below:

(1) First off - the sky isn't falling. There's a big difference between using a cryptographic hash for things like security signing, and using one for generating a "content identifier" for a content-addressable system like git.

(2) Secondly, the nature of this particular SHA1 attack means that it's actually pretty easy to mitigate against, and there's already been two sets of patches posted for that mitigation.

(3) And finally, there's actually a reasonably straightforward transition to some other hash that won't break the world - or even old git repositories.

Anyway, that's the high-level overview, you can stop there unless you are interested in some more details (keyword: "some". If you want more, you should participate in the git mailing list discussions - I'm posting this for the casual git users that might just want to see some random comments).

Anyway, on to the "details":

(1) What's the difference between using a hash for security vs using a hash for object identifiers in source control management?

Both want to use cryptographic hashes, but they want to use them for different reasons.

A hash that is used for security is basically a statement of trust: and if you can fool somebody, you can make them trust you when they really shouldn't. The point of a cryptographic hash there is to basically be the source of trust, so in many ways the hash is supposed to fundamentally protect against people you cannot trust other ways. When such a hash is broken, the whole point of the hash basically goes away.

In contrast, in a project like git, the hash isn't used for "trust". I don't pull on peoples trees because they have a hash of a4d442663580. Our trust is in people, and then we end up having lots of technology measures in place to secure the actual data.

The reason for using a cryptographic hash in a project like git is because it pretty much guarantees that there is no accidental clashes, and it's also a really really good error detection thing. Think of it like "parity on steroids": it's not able to correct for errors, but it's really really good at detecting corrupt data.

Other SCM's have used things like CRC's for error detection, although honestly the most common error handling method in most SCM's tends to be "tough luck, maybe your data is there, maybe it isn't, I don't care".

So in git, the hash is used for de-duplication and error detection, and the "cryptographic" nature is mainly because a cryptographic hash is really good at those things.

I say "mainly", because yes, in git we also end up using the SHA1 when we use "real" cryptography for signing the resulting trees, so the hash does end up being part of a certain chain of trust. So we do take advantage of some of the actual security features of a good cryptographic hash, and so breaking SHA1 does have real downsides for us.

Which gets us to ...

(2) Why is this particular attack fairly easy to mitigate against at least within the context of using SHA1 in git?

There's two parts to this one: one is simply that the attack is not a pre-image attack, but an identical-prefix collision attach. That, in turn, has two big effects on mitigation:

(a) the attacker can't just generate any random collision, but needs to be able to control and generate both the "good" (not really) and the "bad" object.

(b) you can actually detect the signs of the attack in both sides of the collision.

In particular, (a) means that it's really hard to hide the attack in data that is transparent. What do I mean by "transparent"? I mean that you actually see and react to all of the data, rather than having some "blob" of data that acts like a black box, and you only see the end results.

In the pdf examples, the pdf format acted as the "black box", and what you see is the printout which has only a very indirect relationship to the pdf encoding.

But if you use git for source control like in the kernel, the stuff you really care about is source code, which is very much a transparent medium. If somebody inserts random odd generated crud in the middle of your source code, you will absolutely notice.

Similarly, the git internal data structures are actually very transparent too, even if most users might not consider them so. There are places you could try to hide things in (in particular, things like commits that have a NUL character that ends printout in "git log"), but "git fsck" already warns about those kinds of shenanigans.

So fundamentally, if the data you primarily care about is that kind of transparent source code, the attack is pretty limited to begin with. You'll see the attack. It's not silently switching your data under from you.

"But I track pdf files in git, and I might not notice them being replaced under me?"

That's a very valid concern, and you'd want your SCM to help you even with that kind of opaque data where you might not see how people are doing odd things to it behind your back. Which is why the second part of mitigation is that (b): it's fairly trivial to detect the fingerprints of using this attack.

So we already have patches on the git mailing list which will detect when somebody has used this attack to bring down the cost of generating SHA1 collisions. They haven't been merged yet, but the good thing about those mitigation measures is that not everybody needs to even run them: if you host your project on something like http://github.com or kernel.org, it's already sufficient if the hosting place runs the checks every once in a while - you'll get notified if somebody poisoned your well.

And finally, the "yes, git will eventually transition away from SHA1". There's a plan, it doesn't look all that nasty, and you don't even have to convert your repository. There's a lot of details to this, and it will take time, but because of the issues above, it's not like this is a critical "it has to happen now thing".

Post has attachment
Значимые типы и ООП (в дотнете)
Как-то не в первый раз встретился в интернетах с мнением, что значимые типы в дотнете как-то ортогональны ООП, что ООП совсем не про них. Обидно стало за милые сердцу структурки и руки снова добрались до блога. Самая важная вещь, на мой взгляд, которая опре...

Post has shared content
Nullable reference types and nullability checking in C# 7

Очень интересно! 

Несколько важных моментов:

Вместо создания non-nullable версии типов решено вывернуть систему типов наизнанку: использовать существующие реф. типы как non-nullable типы и ввести нотацию для nullable типов (T?).

Это очень разумный шаг, поскольку большинство ссылочных переменных в приложении являются non-nullable! Именно так сделали когда-то в Eiffel, но реализация была несколько иной. Поэтому переходим к следующему интересному моменту.

Никаких 100% гарантий отсутствия null dereferencing + генерация предупреждений при попытке разыменования nullable типов + возможность включить/выключить проверки на уровне сборок.

Подход интересен тем, что авторы постарались сделать свое решение обратно-совместимым с существующим кодом, но c простыми шагами для миграции. Новый компилятор будет добавлять атрибут в генерируемую сборку, который скажет, произошла ли миграция на новую версию и должны ли клиенты сборки рассматривать обычные реф. типы, как non-nullable. Это, например, позволит потреблять новые сборки старыми компиляторами, которые ничего об этом атрибуте не знают.

Аналогичная картина есть и на стороне потребителя: клиент сборки может отрубить проверки nullability, и тогда компилятор вместо предупреждений о потенциальном разыменовывании пустоты будет выдавать информационное сообщение - "ты тут, кажись, не прав, но продоложай, продолжай, я тебе не мешаю".

В общем, очень интересно, будем посмотреть на первые реализации этого дела.

UPDATE: 
И еще две ссылки.
* C# Design Notes for Jul 7 2015 - https://github.com/dotnet/roslyn/issues/5031
* C# Design Notes for Aug 18, 2015 - https://github.com/dotnet/roslyn/issues/5033

Post has shared content
О радостях TerminateThread
Просто отличная статья от Реймонда Чена по поводу вреда TerminateThread.
Там есть определенное количество низкоуровщены, но проблема описана прекрасно:
>> One case where it is okay to use Terminate­Thread is if the thread was created suspended and has never been resumed. I believe it is perfectly legal to terminate it, at least in Windows Vista and later.
> No, it is not "perfectly legal," for certain values of "perfectly legal." What happened is that Windows Vista added some code to try to limit the impact of a bad idea.
> In this case, it's like saying, "It's okay to run this red light because the city added a delayed green to the cross traffic." The city added a delayed green to the cross traffic because people were running the light and the city didn't want people to die. That doesn't mean that it's okay to run the light now.
И потом, прекрасное, о причинах появления TerminateThread: изначально такой функции не было, и ее добавили под "давлением общественности". Уверен, что технари просто не смогли отбиться от назойливых customer-ориентированных менеджеров, которые так хотели сделать "пользователям приятное":
> Now the history.
> Originally, there was no Terminate­Thread function. The original designers felt strongly that no such function should exist because there was no safe way to terminate a thread, and there's no point having a function that cannot be called safely. But people screamed that they needed the Terminate­Thread function, even though it wasn't safe, so the operating system designers caved and added the function because people demanded it. Of course, those people who insisted that they needed Terminate­Thread now regret having been given it.
> It's one of those "Be careful what you wish for" things.
Очень, ИМХО, поучительная история.

Post has shared content
Бум ждать! Надеюсь не выйдет как с х-трейл, когда ждал-ждал, а то что привезли собирается под боком, да ещё и дизель только на механике :о(
Meet the All-New ‪#‎Tucson‬: a bold, athletic SUV with sleek lines and the distinctive Hyundai grille. Get to know all the angles of the All-New Tucson from its World Premiere at the Geneva Motor Show press conference.

‪#‎Hyundai‬ ‪#‎HyundaiTucson‬ ‪#‎AllNewTucson‬ ‪#‎GIMS‬ ‪#‎WorldPremiere
PhotoPhotoPhotoPhotoPhoto
2015-03-04
6 Photos - View album

Post has attachment

Post has shared content
Happy Friday, everyone.  We want to wish Sophie Turner (+Game of Thrones' Sansa Stark) a very happy 18th birthday today!
Photo

Post has shared content
╔════════      ೋღ♥ღღೋ     ════════╗
ღılıllılı ☆♫  Я сказал, успокойся!  ♫ ☆ ılıllılıღ
ღılıllılı ☆♫       I said, calm down!    ♫ ☆ ılıllılıღ
╚════════   ೋღ♥ღღೋ      ════════╝
Animated Photo

Post has attachment
Регистрация windows — сервисов
Наверное, многим программистам приходится иметь дело с windows—сервисами.
Часто - с теми, которые пишутся ими самими или коллегами.
Такие сервисы имеют интересную особенность - разрабатывая их или обращаясь к ним в своём коде часто удобно
запускать се...

Post has shared content
Wait while more posts are being loaded