|
Just when you thought, "Hey, I'm not being tortured enough." Behold! 10-Letter Wordle
3/6
⬛⬛🟨⬛⬛⬛🟩⬛⬛🟨
⬛🟩⬛🟨🟨🟨🟩⬛⬛⬛
🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩
Link to the exact puzzle.
I totally cheated btw, because there ain't no way.
Jeremy Falcon
|
|
|
|
|
A month and a half ago, when my code-signing certificate was expiring, I found that a simple renewal was not possible...the rules had changed and there were only 2 choices.
0): depend on their hosted service to manage certs/signing
1): get an eToken h/w dongle for a hefty fee
IIUC, option 0 meant uploading/downloading which isn't attractive, especially if signing is part of an existing automated deployment process, so I went with option 1.
The little blue usb device arrived a few weeks ago, and has been sitting on my desk with an instructive little business card daring me to try it...'To set up and start using your Code Signing token, please go to http://theirwebsite...blah, blah'. (kinda funny they use http)
Well, today is the day. If I follow the instructions carefully, it should go smoothly. 
At step 4, it reminded me that I needed that one-time-available-only password from step 2.  What password?  There was an initialization code, but no password. Oh well, there's an option for when you don't know the password. (rabbit hole) Something I did caused an unhandled exception and the tool crashed. When I bring it back up, I'm still unable to change the password per the instructions. (if you don't know the token password, you it's useless) Finally, I called for support.
I got the cert reissued and went through the process again, but this time actually knowing the correct password and got through the process of installing the certificate. But how do I know that it works?
Google finds me an obscure link to a Japanese site where a utility can be downloaded. I download and start it. There's an option to sign/timestamp an executable...and it works the first time! 
Now that I know it works, I can move on the get it integrated with signcode in the chain. I already have some sample code from @RickZeeland to get me started. Thanks again Rick!  It's been a busy Friday so far...now, on to more little victories!  Have a great weekend!
"Go forth into the source" - Neal Morse
"Hope is contagious"
|
|
|
|
|
That subject line.
Please never use it ever again, especially on a site where a bunch of aging software developers hang out.
|
|
|
|
|
"Hang out"?
Hoist on your own complaint, me thinks. 
TTFN - Kent
|
|
|
|
|
Wordle 1,091 4/6
⬜🟨🟨🟩⬜
🟨🟩⬜🟩⬜
⬜🟩🟩🟩🟩
🟩🟩🟩🟩🟩
|
|
|
|
|
Wordle 1,091 4/6
⬜🟨🟨🟨⬜
🟨⬜🟩🟩🟩
⬜🟩🟩🟩🟩
🟩🟩🟩🟩🟩
|
|
|
|
|
Wordle 1,091 4/6*
🟨⬜⬜⬜⬜
⬜🟨🟨⬜🟩
⬜🟩🟩🟩🟩
🟩🟩🟩🟩🟩
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Wordle 1,091 4/6
🟨⬜⬜⬜🟨
⬜🟨⬜🟨🟨
⬜🟨⬜🟩🟩
🟩🟩🟩🟩🟩
|
|
|
|
|
⬜⬜🟨⬜⬜
⬜⬜⬜🟨⬜
🟩🟩🟩🟩🟩
Good but lucky guess
In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity. - Hunter S Thompson - RIP
|
|
|
|
|
Wordle 1,091 4/6*
🟨🟨🟨⬜⬜
🟨🟩🟨⬜⬜
🟨🟩⬜🟨⬜
🟩🟩🟩🟩🟩
Happiness will never come to those who fail to appreciate what they already have. -Anon
And those who were seen dancing were thought to be insane by those who could not hear the music. -Frederick Nietzsche
|
|
|
|
|
Wordle 1,091 5/6
🟨🟨⬛⬛⬛
⬛🟨🟨⬛⬛
⬛🟩⬛🟩⬛
⬛🟩🟩🟩🟩
🟩🟩🟩🟩🟩
Ok, I have had my coffee, so you can all come out now!
|
|
|
|
|
Wordle 1,091 3/6
⬛⬛🟨⬛🟩
🟨🟨⬛⬛🟩
🟩🟩🟩🟩🟩
Jeremy Falcon
|
|
|
|
|
From the CP newsletter about how a new language will fix all problems that come from C++
Swift the best choice to succeed C++, Apple says | InfoWorld[^]
For a few years I was a principle security reviewer for a financial application. It wasn't written in C++ but that certainly didn't make me think that it wasn't possible to introduce security problems.
And I looked up top security problems in 2023. I only got above halfway down the list but I didn't see any that seemed to be caused by C++ pointer errors.
Qualys Survey of Top 10 Exploited Vulnerabilities in 2023 | Qualys Security Blog[^]
Matter of fact when I was a security reviewer I got to see a private study produced by a company that made quite a bit of money from cleaning up security problems that companies had.
And in that study something like 90% of the problems were caused by internal bad actors.
Rather pointless to obsess about whether your pointers are safe when the CEO is using internationally set up companies to ship fake orders and thus prop up the companies stock (real case.)
|
|
|
|
|
Back when I was a teenager and the Internet was a fresh thing to most people I spent my time getting into systems I didn't belong in.
And most of the time I got there by using buffer overrun attacks on services that should have never been Internet facing to begin with, like a network print daemon (citing a specific example that allowed me to identd on efnet as freshmeat@usda.gov )
My point is, this used to be common, at least in the wild west days of the Internet, so I wonder how much of the fact that it doesn't seem to be so common now has to do with better practices, better libraries, and such in C and C++. For example, Microsoft produced a bunch augmented functions to the C runtimes that take lengths which they check so you can't overrun them. Things like strcat_s? and stuff. I don't really use them because I don't do a lot of C++ on Microsoft's compiler, but it made me think of that.
Also, probably less services are written in C or C++ now that machines are cheaper and faster.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
I don't use the strcat_s family of functions either. I find that strncpy, strncat, and snprintf handle things quite well.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
TBH, so do I. If I was pressed I probably couldn't tell you what the actual benefit of the _s functions are - only what MS presented them as.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
I believe their claim is they use sizes that are automatic so you can't "lie" to them. My view is this is C/C++ and I trust myself. I wouldn't use the language if I didn't.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
Greetings Kind Regards char*? wchar_t*? Why not std::basic_string<char> std::basic_string<wchar_t>.
|
|
|
|
|
You'd be surprissed how many services are "internet" facing even though they should never be... not even basic security considered. Recently had an incident where a RDP connection was possible to a server holding / running finicial data for multiple companies... not even a FW or anything inbetween... scary sometimes
Who the f*** is General Failure, and why is he reading my harddisk?
|
|
|
|
|
I'm not surprised.
But you have understand that in 1994, almost everyone was vulnerable.
It's relative.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
I would say that you have a category error here. One must divide the security breaches into unauthorized access, and authorized access to perform unauthorized actions. The first encompasses all "hacking" attempts (buffer overruns, SQL injection, etc. etc.), while the second encompasses the "inside jobs".
Secure languages are an attempt to mitigate "hacking". Proper procedures are one way to mitigate "inside jobs" and designing them is at least as difficult as designing a secure language.
C++ already has the neccesary mechanisms for producing robust code - unique_ptr<>, shared_ptr<>, string, vector, etc. The problem IMO is the legacy code ported from C, and new code that uses ordinary pointers and buffers in a misguided attempt at optimization.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Quote: C++ already has the neccesary mechanisms for producing robust code - unique_ptr<>, shared_ptr<>, string, vector, etc. The problem IMO is the legacy code ported from C, and new code that uses ordinary pointers and buffers in a misguided attempt at optimization.
The problem is also code written before C++11, when those pointers became available. It won't get retrofitted unless it has problems attributable to pointers, which it typically won't given the time it's had to soak. For new code, I think failing to use the things you mentioned is less a case of misguided optimization and more one of ignorance on the part of those who never progressed beyond the pure C way of doing things.
|
|
|
|
|
Without pointers, programming languages are pointless.
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
It's just too easy to make a serious mistake even if you do know what you are doing and are extremely good at it. Meanwhile, the penalty for near any such failure is near inevitably RCE or privilege elevation with both basically throwing the doors wide open for the barbarians at the gates.
It's also "just how things are done", using pointers and pointer arithmetic. Maybe you can make a performance argument in a very few cases. (Why are they pythoning all the ML stuff instead of C++?) Mostly though, we aren't seeing superior products as a result, but inferior ones, not in terms of performance, but security. And it's just not worth it anymore to use these unless you just don't have a choice. The situations where that holds true are shrinking fast. They'll be gone inside a decade when I think it will be totally reasonable to expect something like a .NET-on-chip and other similar such inroading into embedded development.
|
|
|
|
|
If you're looking at technical issues leading to security issues, then null-terminated buffers are the number one problem, followed by use after free and then reading uninitialized buffers.
If you're looking at all sources of security issues, people are by far the number one cause of security incidents.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
