-
Fully hipster compliant if you ask me :D
-
-
Were you doing a Leon3 port, too?
http://soc.microsemi.com/products/ip/search/detail.aspx?id=635
All these heavy-weight, closed, possibly-backdoored CPU’s people are using these days for BCHS stacks. I’d rather just macro-assembler it on a GPL’d CPU I can customize and understand. Open cores also let you do other neat things to improve security later on.
https://people.csail.mit.edu/nickolai/papers/zeldovich-loki.pdf
-
-
-
This is a pretty good post.
The author should spend a little more time on the distinctions between IVs and nonces (this is a problem in the literature as well) because the constraints on both are subtly different. An IV is an implied first ciphertext block, and in CBC it needs to be unpredictable. A nonce is a number used just once; it is less important that a nonce be unpredictable, and in fact in some constructions (GCM being a good example) a random nonce can be problematic.
I’d also nitpick that there are probably much more important common developer crypto mistakes that should push out, for instance, not using password hashes or having incoherent crypto designs. For instance:
-
Directly using RSA to encrypt plaintext (and, relatedly, using RSA without secure padding).
-
Failing to authenticate associated data (such as the IV of a CBC ciphertext.
-
Compressing before encrypting.
I might also instead of recommending RSA-2048 and discussing key sizes instead just push people towards Curve25519.
-
-
-
A few reasons, one you can only encrypt things with RSA up to the size of the key, so if you want to encrypt a large message you just can’t in a single shot with RSA. You might design some sort of multi-RSA-encryption scheme, but then the problem you face is that RSA encryption is significantly slower than a symmetric cipher like AES.
Finally, I’d like to note that in general I think people should be skeptical of designs that involve encrypting anything with long-term RSA keys: https://alexgaynor.net/2017/apr/26/forward-secrecy-is-the-most-important-thing/
-
Also: the amount you can encrypt per “block” is deceptive, because there’s an amount of padding necessary for security, and encrypting correlated bits under RSA makes error oracle attacks more feasible. There is in practice virtually never a reason to encrypt directly with RSA.
-
-
-
-
Add 2015 to title?
-
-
I currently use fossil for a side-project, but I’ve been keeping an eye on self-hosting git servers, mostly for easier github mirroring. gitly is the one that currently has my interest, as it’s the only git server that seems to have the features close to what fossil and is built to run on servers with less an 1GB of RAM, (as opposed to Gogs or Gitlab).
I wonder what it would take to rectify these things in fossil itself?
-
-
Not for basic usage, but gogs (at least) has other strange performance issues. For instance, every time the file tree for a repository is loaded, it checks the git history for the last commit to modify that file. On tiny repos, this isn’t too bad. However with a 100-200 file ASP.net website, the file tree (front page for a repository) can take 5-7 seconds to open, with no load on the server. I don’t want to put something like that in front of the internet. Gogs doesn’t target a low resource use case, where fossil does. And, according to their press release, it looks like gitly does as well.
-
I know this isn’t as turnkey as Fossil, but if you set Gitea (and I assume Gogs) to use any form of cache other than 60-second in-memory, the file tree shouldn’t be as expensive. Been awhile since I played with this, but I remember hitting and quickly resolving the same issue.
-
https://github.com/gogits/gogs/issues/1518 is an issue covering it in Gogs. Looks like gitea is still in the process of working on it as well, or at least something similar https://github.com/go-gitea/gitea/issues/502
Is the caching that you’re talking about something akin to 20-minute caching in memory, or do you need to go for redis or memcached for this?
-
-
-
https://docs.gitea.io/en-us/#system-requirements They say that you can run it at a basic level on a Raspberry Pi, but that a 2 core / 1GB RAM server is the baseline for teamwork. That’s not very descriptive, to be honest, but on my 512 MB ram server, I’m not exactly curious to find out, since fossil is currently working for me (if there are compelling reasons to switch away from fossil, I will). It could be that 1 GB is just for teams of 20+ people, or just a comparison based on bottom tier Linode instead of something like Ramnode or Vultr, but I don’t know.
If Gitea were 100% Go based, I’d suspect that the 1GB is actually plenty of headroom, but it also interacts with git, and currently has the slightly strange file tree browsing issues that haven’t been locked down yet (as mentioned in other comments).
This is in strong contrast to fossil, which explains how it an be used in a shared host CGI environment. It also explains which actions can be rather slow (mostly building tarballs/zip archives, and it offers a cache for those). It also helps that the default page for fossil doesn’t show a directory listing, but that’s another discussion.
-
-
-
I’m watching and interested it, but I’m not sold on it yet. I won’t be using until it is properly open sourced, but the claims that he is making are worth like they’re worth watching.
As far as the lack of source and the use of a web form, I think it’s a bit early to call it shady rather than just MVP, at least for now. It’s not confidence inspiring, to be sure, but I’ll give him the benefit of the doubt until April 10th. Fossil isn’t going anywhere, and is serving my side-project needs just fine for now.
EDIT: It looks like one of the example repositories, from Tensorflow, has been removed in some fashion. Something does seem to be afoul.
-
-
-
-
The price! ?
-
Is there something wrong with my browser or were there just three sets of numbers on that blog post? How about most downloaded apk and many other interesting numbers?
-
-
Excellent! This is what Matrix was missing
-
I’d be 100% down with a peer to peer syncing solution, but considering they’re using azure to store everything centrally it makes me question how they intend to sustain this service and their longevity.
-
bitwarden is currently sponsored by the Microsoft BizSpark program which covers many of our operation costs and allows us to offer services for free to our users. We are working on our monetization strategy which will introduce additional premium features in the future. For now though, everything is free for users.
-
-
I use pass to manage my passwords, and instead of using the integrated Git support for syncing, I know I’ll get lazy and forget to commit and push at times, I use Syncthing to keep everything in sync across all my devices. Syncthing works very well for me, easy to install and configure and adding other devices is trivial to do.
-
-
IPFS is great! I’ve used it to sync large files between my home and remote nodes from time to time.
If all you keep are website + password pairs (no username/login ID), then even if the encryption employed by IPFS is “broken”, the risk profile is still very low as any intermediary node that has a copy of your file will have no way of figuring out which user ID to pair with the password.
-
-
-
-
Would be nice to have an edition digitally signed by 40 developers. Might make it a little easier to verify the releases than it is today :)
-
-
bigdubs
edited
1 year ago
|
link
| on:
Websocket Shootout: Clojure, C++, Elixir, Go, NodeJS, and Ruby
How to know someone isn’t really doing a lot of golang programming; throwing the unlock after the critical section without a defer.
-
-
-
You don’t always have to use defer, but banning it seems insane to me. If a little extra garbage is unacceptable for your service, apply targeted fixes after profiling, or Go is not the right language for your tasks.
-
We banned defer for many reasons, defer also has serious safety implications when used with Unlock along with go’s panic/recover(), you can essentially get corruption in memory when go runs off and pops up the stack on a panic while allowing other threads to just stay executing. That was the real reason we banned it. I find it to be the least elegant and least thought out part of the language. I hope for significant changes in panic, defer, and recover in 2.0
That’s an aside though – this post is about a shootout! I hope anyone who codes for a language shootout attempts to reason about their memory usage/gc behavior in tight loops.
If you’re using garbage collected language and you’re not reasoning about garbage collection, then you’re being sloppy. It’s up to you whether that’s acceptable or not.
Finally - i disagree wholeheartedly with your comments about targeted fixes. In my career it has rarely been the right choice, and performance has been the #1 reason why groups I’ve worked in have had to rewrite huge portions of large systems.
-
We banned defer for many reasons, defer also has serious safety implications when used with Unlock along with go’s panic/recover(), you can essentially get corruption in memory when go runs off and pops up the stack on a panic while allowing other threads to just stay executing. That was the real reason we banned it. I find it to be the least elegant and least thought out part of the language. I hope for significant changes in panic, defer, and recover in 2.0
Do you know if there’s an issue tracking this problem or an otherwise more detailed description of what’s happening?
-
Don’t know about their issues / bug tracker. I have repro’d the issue for you here though: https://play.golang.org/p/fMEWFPPr6r
I had to download it locally for it to actually show the issue:
; go run test.go 1 thread1 val++: 1 val = 1 thread2 val++: 2 panic: bad [recovered] panic: bad goroutine 5 [running]: panic(0x48c580, 0xc420078020) /usr/lib/go/src/runtime/panic.go:500 +0x1a1 main.thread1.func1() /home/codemac/test.go:24 +0xeb panic(0x48c580, 0xc420078020) /usr/lib/go/src/runtime/panic.go:458 +0x243 main.thread1() /home/codemac/test.go:30 +0x14a created by main.main /home/codemac/test.go:41 +0x35 exit status 2 ;Now - I recognize that races are part of MP programming, and that this example is a little crazy, but I hope it illustrates the point that using panic as both os.Exit and as an exception stack leads to unexpected behavior unless you’re careful. Not to mention the oddity that the community of go writes
if _, err := blah(); err != nilall day, but for some reason also wanted a panic that didn’t panic but excepted. In sufficiently bogged down programs, you can complete writes out to the network before a panic has completed.-
I guess I’m having trouble groking the actual issue. Was the expected behavior to not print
thread2 vall++: 2? If so, that doesn’t seem quite right to me. The mutex is unlocked beforethread1re-panics inside thedefer.but I hope it illustrates the point that using panic as both os.Exit and as an exception stack leads to unexpected behavior unless you’re careful.
I agree that relying on panics for
os.Exitbehavior seems weird (and non-idiomatic).I guess what I’m having trouble understanding is:
- Why this led you to ban
defer? - How do you get memory corruption?
-
In a large codebase with a significantly tall call stack, the defer Unlock will be far away and not obvious, and leads to bad accidental bugs, especially with how often the stdlib calls panic. This was a reduced example with two threads just to show the interaction I was trying to describe.
I’m using the term “corruption” in the logical sense: the store to val occurring after the panic was called before to me is an unintended (although explainable) write to memory.
“non-idiomatic”.. look the code I wrote has a bug in it, yes. But if you assume your program will randomly pop up exceptions, then you realistically cannot put Unlock in a defer in a multi-threaded program without stores to sensitive memory (the example in the shootout I might add).
- Why this led you to ban
-
-
-
-
-
-
-
-
-
There are packages that makes these sections more readable. For example: https://github.com/whitecypher/work
-
Oh my! Looking at the example, that’s even worse. Now you need to wrap every computation in a closure! There are far more elegant solutions, even with Go’s limited type system. E.g., from the code:
obj, err := repo.RevparseSingle("HEAD") if err != nil { log.Fatal(err) }Can be converted into:
if obj, err := repo.RevparseSingle("HEAD"); err != nil { log.Fatal(err) }Or just write a small function:
func exitIfError(err error) { if err != nil { log.Fatal(err) } } // ... obj, err := repo.RevparseSingle("HEAD") exitIfError(err)Or switch to a language with sum types and monads/macros :). Though, I still have difficulty understanding why the Go team just doesn’t add some syntactic sugar to let errors bubble up, since
erroris an interface.-
It’s things like this that make Go feel like a spectacular waste of an opportunity to have improved on C. That API could have been more like:
git_repo_t *gr = NULL; git_obj_t *go = NULL; git_commit_t *gc = NULL; if (git_open_repository(repo_path, &gr) != 0 || git_revparse_single(gr, "HEAD", &go) != 0 || git_obj_to_commit(go, &gc) != 0) { warnx(get_errstr()); git_commit_free(gc); git_object_free(gc); git_repo_close(gr); return (-1); } return (0);
-
-
-
-
-
lattera
2 years ago
|
link
| on:
Open Whisper Systems partners with Google on end-to-end encryption for Allo
Though I really like that Allo has that capability, I wish it was universal rather than just in Incognito mode. This means that Google can track who uses Incognito mode and when.
-
Everybody wants secure end to end encryption. Or they think they do. I suspect if people were given what they say they want, they’d quickly revolt.
Right now, I can think of some popular run arounds to encryption. Both iMessage and WhatsApp allow you to backup your chats. By necessity, this means they are available to devices other than those originally involved in the conversation. Otherwise, what good is the backup?
Soon we’ll get a “really secure” chat app, or the settings change to disable all backups will become popular. Wait six months as people lose their phones. WHERE DID MY MESSAGES GO? I didn’t even know these things were backed up until I switched phones, but the discovery was really convenient. I mean really convenient. My old message queue is an archive of all the phone numbers and addresses and door codes I never quite got around to saving. I suspect a lot of people will like, omg, literally die if their old messages are lost.
-
Last I checked, WhatsApp’s backup is simply a set of snapshots of their on-device database. When you lose your phone, you lose your messages.
(Or if the sqlite database gets corrupted and the encryption keys have rotated recently, then you lose all your messages, despite said backups. See me, screaming in anger at WhatsApp in February 2015.)
-
-
-
-
Exciting! I have been playing with the same idea lately and finally got to start implement it this morning. You beat me to it! ;-)
-
Unless they are very, very, very good bots. Chances are your bot kinda sucks and works like a flaky command prompt.
-
-
I wonder how this compares to SQRL, apart from the personal controversy around the author of SQRL
-
Looks like a nice solution to the problem. Although I do have a couple of quips with it. Most of the 2FA I use at the moment is using google authenticator / authy so the whole ‘no need for text messages’ isn’t really a big incentive to me. Also a box with text saying “Straightforward, low-cost pricing.” which then leads to a contact the sales team for pricing page is a bit of an antipattern in my books.
Also, and more of a technical/semantic question but if it removes the password is it really two factor authentication? I understand the need to use familiar terminology but it feels more like a one time password solution that two factor.
-
…a box with text saying “Straightforward, low-cost pricing.” which then leads to a contact the sales team for pricing page is a bit of an antipattern in my books.
Looks like they designed their App Store page for users and their website for clients.
…it feels more like a one time password solution that two factor.
It’s just OTP, but “2FA++” is a better pitch for clients considering other 2FA solutions.
-
quip
noun
1. a witty remark.I don’t think that’s what you meant. “qualm”, perhaps? I only mention this because I remember making the same mistake and feeling very embarrassed.
-
-
-
-
-
I can’t take this seriously if something as basic as “Uses Javascript” (literally any Javascript) carries a bigger penalty than not using HTTPS.
-
Come to think of it, a nice addition to the HTML-standards would be to allow adding an “optional” tag to <script> elements, indicating that a script is optional and can be ignored without breaking the site. Then users could choose in their settings if they want to allow optional Javascript or not.
-
-
Of course, but that wouldn’t be any different from today (every <script> is non-optional today). I get your point though and there probably have to be other approaches to this issue.
-
Taken from a performance perspective, however, this may actually be a good idea. Users could opt out of optional javascript if they’re internet service was slow.
-
-
-
-
I totally agree with you, but the web is a sucky place and the majority of web developers is not accustomed to the art of making websites which work with and without Javascript. In my opinion, this is a sad situation.
-
-
-
-
There hasn’t been much news on that site in a while… Is it still being developed actively?
-
TLDR: I don’t like smartphones because they are not PCs.
This comment was brought to you using a smartphone.
-
But I’m sure you also own a PC for all the real work, right? The problem the author points out is that more and more people don’t even own PC’s anymore, given there are less and less primary incentives for that. Even kids nowadays mostly spend their money on expensive smartphones, there’s often no money left for a computer.
Later on, when a kid might come up with an app idea, which can we a secondary incentive, there then won’t be a PC to work on those things. It may sound funny, but this is a real problem, and it will be devastating.
-
-
I totally agree with you - people who use an ipad today are unlikely to be have been type who used the PC as a creation device.
What we are slowly losing is the malleability of a PC in the house. I would bet that a there are many adults in comp-sci that started off with tinkering with the home PC that was probably bought to help the family do taxes or write school reports. It is becoming harder and harder to come across that kind of opportunity today.
-
-
The implicit assertion here is that PC’s will remain the only viable way to make things. Something like TouchDevelop is still toy-ish but I’ve been able to make little games and apps while sitting at bars. I think what we have so far is primitive compared to the possibilities, there’s still so much to explore.
-
But I’m sure you also own a PC for all the real work, right?
More and more people are shifting entirely to tablets and phones for “real work” – or more specifically – all their work. I have seen this first hand, a friend of mine has been living without a “classic computer” since the iPad Pro release. He does 100% of his work on his iPhone and has iPad Pro and claims he is more productive than ever. Companies are doing this as well – as iPads are easier to maintain.
I suspect (for better or worse), the general purpose programmable computer will be a specialized tool used by engineers and will fall out of the consumer space in the next couple decades. Developers will rage about it – and it won’t matter. Just like when people raged about the inability to repair their own cars due to growing computer control and complexity – and it didn’t matter.
-
General purpose computers have not been an unqualified success for non-technical users; is it any surprise that people drowning in a foetid sea of viruses, malware, Windows, MDI, the OS X Finder, et al would grab hold of the first lifeline that allowed them to simply get on with their technologically mediated lives?
-
More and more people are shifting entirely to tablets and phones for “real work” – or more specifically – all their work.
I don’t really buy it, because the tablet market is stagnating - sales are shrinking. Admittedly, the PC market also hasn’t been great, but in contrast to tablets, many six year old Windows 7 PCs can still run current software fine. So, there is less incentive to buy a new PC every three years.
He does 100% of his work on his iPhone and has iPad Pro and claims he is more productive than ever.
As long as we don’t have statistics over a large population, this is just an anecdote. Of course, there will be some people who use just tablets.
I think general purpose computers aren’t dying yet, because (1) people keer around and use their old PCs; and (2) cheap Windows laptops are approximately in the same price bracket as usable tablets or Chromebooks. I do agree that usage patterns have changed a lot to move from local applications to cloud applications. So, there could be a rapid change from general purpose computers with a keyboard to computers that only have a browser (and a keyboard).
I am two-minded about this. For the general population, computing will be safer. Family incidents like malware, lost files, viruses, etc. will be fewer. But it’s indeed also harder for someone who would like to hack on their system to do so.
[1] http://www.dailytech.com/Its+Official+the+Tablet+Market+is+Stagnant/article37123.htm
-
-
-
The e2e encrypted chat has a subscription model. I wish this were the private communication platform it claims to be. The closest we have now is keybase, which is not optimal either
A subscription model itself is not bad. But if they are selling themselves as a private communication network, it’s strange that the only privacy friendly piece is the one that costs extra.
I’m interested in your opinion on the deficiencies in keybase. What features would you change or add?
If I were to introduce keybase as a communication platform for my less tech interested friends and family, it would have look more like what MeWe looks like. A chat/social network/shared photos.