Open-source vuln db closes – plenty of taking and not a lot of giving The organizers of the Open Sourced Vulnerability Database (OSVDB) have announced they are having to shut up shop. "A decision has been made to shut down the Open Sourced Vulnerability Database and [it] will not return. We are not looking for anyone to offer assistance at this point, and it will not be resurrected in its …
You just give me a warm feeling all over :-)
Not content to be an renowned system hog of questionable efficacy, using the dubious means of marketing yourself via bloatware on innocent new systems, it turns out you are also a mooching lowlife.
I see why your founder holds you in such high esteem.
Do you have suggestions?
I think you'd have a captive market.
Don't blame the devs, smarter minds than ours have tried to develop secure systems. The problem, as I see it, is that a computer is essentially a calculator and a pad of paper (memory) - now, how do you stop someone fiddling with those without physically holding on to them and physically overpowering anyone who tries?
Only if you can "secure" the lowest level, can you build something on top. Now, that's not too say you can't build a mighty fine system that keeps a lot of people out; I just mean I'm not sure you can build a perfect one.
Ook: http://www.dangermouse.net/esoteric/ook.html
Even more obscure than any of these, however, was NNAPL*.
It has no data types beyond INT and (iirc) STR and requires you to define your data structures by the number of bytes they will require - /and/ you have to remember to add two bytes to the total for each for a CRLF at the end of each of them.
It's entirely possible to add 144 to 'last Tuesday'.
Try working out wtf I was doing when I wrote /that/ code - even I don't have a clue what it's doing ;)
* Neural Net Application Programming Language.
Malbolge is over-engineered. Use something elegant, like Unlambda. Only three operators to learn, and their functions are trivial to remember.
While the Turing Tarpit and malevolent languages are fun, the best esoteric languages are the ones that someone intended in all seriousness to be used for real work. Someone_Somewhere mentioned NNAPL; another is the scripting language for the prosody analysis tool Praat. Array indexing by string interpolation is clearly a programming-language innovation whose time has come.
Put simply, it's impossible to create an entirely "secure" development language/environment. All it needs is for an algorithm to be incorrect or not thought through fully and that's security "broken", and this algorithm could be anywhere from the lowest level memory management code to a public access statistics report.
Doesn't mean that we can't improve things though.
> Put simply, it's impossible to create an entirely "secure" development language/environment. <
Indeed.
Quite apart from whatever that flaw was that affected all x86 systems prior to 2011*, even open source stuff is no guarantee if you didn't write the compiler yourself.
And even if you did, what did you compile /that/ with?
* can't remember off the top of my head bnut it was reported on the Reg a few months ago.
> Put simply, it's impossible to create an entirely "secure" development language/environment. ... Doesn't mean that we can't improve things though.
Yeah. You can never prove that code does what you think it does (i.e. is correct). The best you can do is to eliminate surprises: pointers, untyped variables, type casting, integer overflows, silent failures in general, fancy string embedding/escaping (big in webdev), cryptic punctuation, unnecessary verbosity, etc. But you have to be careful about adding new surprises (exceptions, garbage collection, arcane type systems) in the name of safety.
Predictability is key. Simple concepts, simple syntax, limited features, deterministic compilation & execution (same source & input -> same exact runtime behavior)
> ...even open source stuff is no guarantee if you didn't write the compiler yourself. And even if you did, what did you compile /that/ with?
Pencil, paper, and an opcode table. You can implement a simple Forth compiler in under 1000 bytes, and use that to bring up the rest of the system. Worst case, you'd have to program it in bit-by-bit using toggle switches. :)
>Pencil, paper, and an opcode table. You can implement a simple Forth compiler in under 1000 bytes, and use that to bring up the rest of the system. Worst case, you'd have to program it in bit-by-bit using toggle switches. :)
Many, many moons ago, I got my hands on.. can't remember the title /exactly/ but it was something along the lines of 'The Sex Lives of Computer Programmers'.
As I recall it, the sex life of the assembly programmer was: Using a protractor and propelling pencil, you spend months planning how you will make love to your girlfriend but, when the time comes, you're enthusiastically buggering the cat. Afterwards you pretend that was what you meant to do all along. :D
Oh, alright then:
C: Every time you make love to your girlfriend your penis points in a different direction but you don't notice until, one day, it points up your own arse.
C++: Because she's cool with it, you get to make love to both your girlfriend and her cousin. Unfortunately they both learned their love-making technique from their uncle and you end sporting an anus like the Japanese national flag.
VB: You proudly unveil your erection before your girlfriend. She says "It looks like you want to wee. Would you like help with weeing?"
ActiveX: Some bastard keeps making love to your girlfriend but you can never catch the fucker at it and don't know how to make him stop."
SQL: You want to make love to your girlfriend but, unfortunately, only one couple is allowed to make love at a time and you have to wait for the whole street to finish first. Afterwards you pretend it never happened and she pretends she was never committed anyway."
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
