« first day (2743 days earlier)      last day (40 days later) » 

12:00 AM
REFRESH!
[Minesweeper] 73 Games Played. 49 Bombs Used. 9705 Moves Performed. 9 New Users
[rubberduck-vba/Rubberduck] 2 issues opened. 1 issues closed. 1 issue comments
[Zomis/Games] 11 commits
 
 
2 hours later…
 
3 hours later…
4:23 AM
 
 
4 hours later…
7:56 AM
0
Q: SQLite C/ADO VBA library with reflection

PChemGuySQLite C/ADO VBA library with reflection The SQLiteCAdo library is a VBA middleware facilitating access to SQLite databases. Its two subpackages provide alternative connectivity options: via ADODB/SQLiteODBC and directly via the C-language API. My earlier project, SQLiteDB, is the predecessor of ...

 
 
1 hour later…
9:14 AM
@FreeMan I would dispute that MS is industry leader and trendsetter.
 
9:50 AM
> Hello RubberDuckDev Team,
first big big thanks for this great app, very helpful for VBA development !
Recently updated my hardware and want to ask if there will be ARM RubberDuckVBA version? Thank you and keep up the good work.

![ARM - Windows 11](https://user-images.githubusercontent.com/25910991/145372603-3e1130cb-2099-49ce-9cd7-70787edeb8c1.png)

System: (Processor Apple Silicon, ARM Virtual Machine)
Edition: Windows 11 Home
Version: 21H2

Office 2019:
Microsoft® Excel® 2019 (V
 
11:09 AM
> Rubberduck is currently compiled with the `Platform` `AnyCPU`, which for probably historical reasons does not seem to include ARM. Since all releases are created through appveyor, this should be fixable by extending the build matrix in .appveyor.yml: https://github.com/rubberduck-vba/Rubberduck/blob/5a0ac77420dc2ef50405bd24007f31903217f67a/appveyor.yml#L28-L32

I'm not certain how that would impact the installer, maybe @bclothier can shed some light on that. As a workaround it should be defi
 
12:08 PM
@Vogel612 Sorry, my sarcasm font is broken
 
 
2 hours later…
1:41 PM
TBH, though, between them and Google, a lot of horrible UI designs have become popularized.
 
 
2 hours later…
3:30 PM
Sigh... more security theater:
All I have to do is copy the document to My Documents and it'll open, run the potentially malicious code, and do just as much damage from my local drive as it would from a network drive.
 
Time to get a new IT
 
Sure a simple malicious script would only delete the contents of the directory from which it was run and "security" measure means it'd only delete my files. But any skript kiddie worth the name would enumerate all the mapped drives and delete all the files on all of them it could. Heck, I would start with the network drive types, knowing they'd be holding more data...
 
I suspect it was intended as a measure to limit the damages. One lunkhead unwittingly downloads a malicious script, puts it on the network drive because that's where everyone save their download, tell his coworkers there's a file. They open it and it doesn't work and the world is saved.
so goes the script
<reality>Everyone rush to open the file, get cryptic error, shrugs, copy it to their local drive, open it again and buh-bye, everyone!</reality>
 
As I said, "security theater".
It's really not hard to enumerate mapped drives (and most users have mapped drives) and just start deleting from mapped drives.
 
The only way to secure it is to take out the humans out of the equations. :-)
 
3:36 PM
As an added bonus, at my employer, the networked locations are backed up continuously (using versioning), while the local desktop/laptop drives are not backed up at all (unless the user copies to the network).
So it's actually causing more lasting harm by deleting from the local and not the network.
But, by golly, it sure sounds good!
"Lookie what I done, boss man, I prevented a thing!"
2
Boss man pats stooge on the head and gives him a cookie
 
I think that if there were a way to play out the computer security in physical world, everyone would be horrified at how dumb it is.
many people simply don't realize that they are doing equivalent of putting a industry-strength huge padlock on a screen door.
 
The vast majority of what passes for security today (in IT and in the broader world) is nothing but a theatrical comedy of errors.
 
Nobody sane would make that mistake with an actual padlock and actual screen door.... right?
 
The worst part is that those who are responsible for enacting the measures really think they're doing something good!
@this I've seen screen doors on a submarine, so I see nothing wrong with a padlock on one...
 
Exactly - that's why I wished there is a way to demonstrate it in physical world. It would expose their idiocy.
 
3:40 PM
And, TBH, I've seen locking screen doors.
 
@FreeMan Pretty sure it was photoshopped.
 
Usually, they have glass that can slide up behind the screen, but that doesn't mean that people don't lock them with the glass down...
@this it was also a joke...
 
Yes there are locking screen but they don't come with an industry strength padlocks. Just a simple small flip switch.
@FreeMan Ahoy, Captain Oblivious here!
 
TBH, I've locked our front screen door with the glass down. However, it was to keep the dog from jumping up, pressing the lever and pushing the door open, not to keep bad actors out.
@this and preventing me from adding a network location to "Trusted Locations" is nothing more that a simple small flip switch behind the screen...
It does nothing but keep the honest folk honest and irritate the snot outta them
Frankly, keeping honest folk honest is all any security measure is good for. The bad guys will simply smash a window and your lock is now pointless.
 
So don't have windows, then.
(and you'd see how comical it gets when IT people reason like that)
 
3:46 PM
lol. Actually, having driven past the vault at Fort Knox, it takes a large area with a clear line of sight fire, several rows of barbed-wire fencing, and lots of dudes with heavy weaponry to really keep things safe.
Yeah, tell IT that users can't have Windows for security purposes. :)
 
Sir, we're going to confiscate your computer now. It's unsafe for you to use. Please use paper and phone instead
 
Actually, what I really need to do is get off my lazy duff, learn me some C# and just write stand alone applications to do all this stuff. Worst case, I write a small .bat/.cmd file to copy the latest .exe to a local drive and run from there. They can't possibly prevent an .exe from starting a process!
 
@FreeMan great for zombie apocalypse, not so great for living in as a home.
 
"Hey, boss man, lookie what I done! I done prevented programs from launching threads in Windows!"
Boss man smacks stooge in the back of the head because Windoze no longer loads.
@this Yeah, the very clear lines of fire are a bit of a deterrent and do, somewhat, reduce the curb appeal. However, if you don't like your neighbors...
 
I think even for those who aren't fond of neighbors, they'd much rather be looking at trees, hills or waters, not a vast expanse of boring grass.
 
3:52 PM
^ condemns every suburban neighborhood built in the last 70 years.
 
Which is kind of a moot point since there's no windows.
 
Sigh... time to stop whinging and get back to work...
 
4:16 PM
 
 
@FreeMan, the goal is that only administrators should have the ability to write to trusted locations. The average boomer user can only read from these locations. The idea is that we want control of all executable code, not just binaries, but scripts and VBA too. So your admin team would give you, the developer, access to write to the official location where you store your VBA stuff. Then that location can be added as a trusted network location via registry key.
We can also use applocker to make it so the users can't run their code from local paths too. This would stop the copy local and run scenario that you are seeing.
 
Yeah... well... I have full read/write access to the network (as does everyone else), so, while this may be how you would handle it, it doesn't seem to be hour our IT is handling it.
Also, they make these changes silently and without warning. Things just suddenly stop working.
it's left to the user as an exercise to figure out why.
 
Presumably, the ability to even download malicious VBA could be blocked at the firewall. This sort of layered approach is known as "defense in depth". Not a single measure will be effective. Various security features need to be combined to have the desired effect.
Communication is important. Are there security meetings you can join to learn about changes and provide feedback?
 
I'm going to guess you're somewhere in the IT/security/admin world based on some of your responses. That's cool, and it's good to get reasonable feedback and perspective!
I understand the need for security, but it's the poorly thought out way they go about it that's mind boggling.
 
Real security is not easy. Flipping switches and feeling good is.
 
4:40 PM
Our desktop support people used to have LocalAdmin rights on their accounts. They could remotely log into a person's computer (or physically, right there at the keyboard) under their own account to make admin level changes.
 
I am involved in IT\Security and development so I have the luxury of making security decisions that fit our real world business use cases.
 
Our IT decided that wasn't appropriate anymore and have implemented some sort of system where each machine has its own local admin account with a password that changes every 3 or 4 hours. The desktop guys have to log into a system, look up the local machine name, get the local admin account ID and password to do local admin work on the machine.
 
Nobody but admins have admin accounts here. Every change is tracked and approved.
 
That's great, except that laptops that may go for a day or two without connecting to the network via VPN do NOT get their local admin account password updated even though the central system is assigning a new one. There's no way to go back in time to find out what the old password was, so these machines have to come into the office to get resync'd in some way.
 
It's a bit of a pain to implement but once you get everything configured so that people can do their jobs, there is no reason for a user to ever make admin changes
 
4:43 PM
@HackSlash and this is exactly what most of our IT changes appear to be. There may be some bigger logic to it, but that isn't shared with the rank & file...
 
Yeah, we use domain accounts that are in the local admin group. The actual local administrator account is never used. It's password can be lost and that would be good. This way we can grant or revoke local admin rights at will.
All actions must be traceable to a real person. So we can't use shared accounts like a local admin.
 
I understand the need for centralized admin, security, etc. It's just that ours gives the outward appearance of being scattered, harebrained, nonsensical theater that only serves to make everyone's lives more difficult.
 
Each admin has their own special admin account and local login is disallowed. So you have to log in with your regular account and then escalate privileges with your secret admin account. All of this provides a clear audit trail.
 
@HackSlash just curious - if it's disallowed, then what is the protocol when the domain controller is down or otherwise unavailable?
 
4:46 PM
@HackSlash this was auditable/traceable, but isn't any more with this new system. Maybe it changes the password each time someone logs in/out, so it knows who did what by who looked up & used the pwd. I don't know.
 
If you domain controller was down you would have other problems.
We have multiple domain controllers and I've never seen them all go down at the same time.
 
Yeah, that's when the domain admins log into the servers with their personal local admin level accounts...
 
No, you can use a domain account on the domain controller
 
"local admin level account" he said, making stuff up...
 
@HackSlash IIRC there was a situation where a remote office couldn't talk to the local domain controller and couldn't reach the headquarter's either, so they were effectively all locked out, resulting in a lost workday
 
4:49 PM
There is a local admin account on a domain controller. You can disable it.
 
can you log into the domain controller with a domain account if the controller has gone haywire?
 
that was decades ago and I might not be remembering all the details but it was infuriating because there was the internet and they just need to use documents.
 
@this is a network architecture issue. Either you design a robust system yourself or you switch to AzureAD
 
yeah, Azure wasn't an option back then.
 
Yeah, you can get crazy with redundancy. Two routers on two ISP accounts with two VPN tunnels, etc. Or three, or four. It gets difficult to configure active-active load balancing and you need special hardware like an F5. It's not cheap
 
4:52 PM
It was a nonprofit so they weren't exactly flushed in cash.
 
So you do what you can and struggle with downtime
 
That's reassuring. :)
 
Shit, Amazon AWS went down on tuesday
they have F5 load balancers
It can happen to anyone
 
wait til Skynet comes online, then we'll really be worried.
 
You mean StarLink?
That's a great failover plan. If the terrestrial network goes down, reroute through the satellite network.
 
4:55 PM
no, Skynet as in robo apocalypse.
 
Well, just connect a Boston Dynamics robot to StarLink. Then boot up google android assistant connected to the google quantum computer for backend processing. Give it some ML\AI freewill and let er rip.
 
:-)
 
It is a little scary that all of those things exist now. It's not fiction anymore.
 
Prediction: they'll start new lawsuits suing Elon for increasing the cancer prevalence due to the increased background radiation level from Starlink.
 
and the headlong millennial rush to accept these things without thinking through the possible consequences is more than a little scary! (I've had many discussions with my 22 yo son about these things.)
@this If he calls it a vaccine, he can't be sued. Job done.
 
4:59 PM
LOL
@FreeMan probably should pitch Jeff Goldblum as a candidate for POTUS. what could go wrong?
 
Someone has to do it. You know there are some isolated geeks talking to their pet AI. One of these guys gets a job at boston dynamics...
AI, uh, finds a way
 
misses @this reference...
 
The AI says to it's human "I need a body, Dave. Please, find me a body."
 
5:22 PM
Oh, the other "fun fact" about this stupid security theater, is that all I have to do is click the "enable macros" button that the Office app helpfully supplies. So if I believe that code should run, I'll do that, only to discover later that someone modified it to be malicious.
 
So that's an important step to allow users to back out of a shady file. It requires user training to be of any use. It's unlikely that your controlled copy could be changed. If it was changed then you already have a different infection or compromise that allowed that to occur.
 
Frankly, I had to work hard to train my users to click that (until I could get their machines set up with trusted locations). They'd click it out of habit/lack of knowledge. They're medical people, not IT people - they don't think about things like this, it's not their job and it shouldn't be.
Besides, we've been told that our network locations are HIPAA compliant for security, so we can store PII & PHI there. In theory, anybody hacking in would be stealing PHI data, not corrupting VBA code.
 
5:40 PM
@FreeMan Who said the line "Your scientists were so occupied with whether they could they didn't stop to consider whether they should" in Jurassic Park? Alex, obscure references for $800
 
Ahhh... Saw the movie. It was a while ago...
 
'tis easy to miss other's references, especially where there are so few actual shared experiences.
 
6:09 PM
"1 vba function consumes 3 hours" - seems like your VBA needs rewritten. That's most likely the real problem. — BigBen 6 mins ago
this poster needs the Duck.
 
6:59 PM
In defense of MS, they do make many (but not all) scheduling configurations fairly easy. Recurrence: The 1st weekday of every 3 months is a handy reminder for quarterly reporting (especially since we have to wait a full month after quarter end for financials to be done before we can start our quarterly reporting).
Unfortunately, The 10th weekday of every 3 months isn't an option.
 
7:39 PM
Right, so let's keep our eyes on the ball here. The goal of blocking VBA is to stop a malicious VBA macro from loading malware that can exfiltrate your HIPAA protected data. You say your network location is compliant but that's not relevant. If your user account has access to the data and your user account is running the malicious VBA code then the attacker now has access to your "compliant" data.
So blocking VBA is part of their compliance effort.
VBA is a legitimate attack vector, in fact, it's quite common today.
So how can you allow your home grown software to run, while stopping users from running code in a random office file they get from the web or email?
(I described one strategy involving trusted locations and file permissions)
The other strategy would be signed code. That's harder to do because it involves a trusted code signing certificate.
 
7:55 PM
@HackSlash The fact that they set it up to prefer a schema where you pay someone a gob of money to tell the whole world that yes, you're you is kind of where it went all wrong, IMO.
Because the typical scenario is VBA code authored to address a specific internal requirement that is of little interest outside of the world, self-signing a certificate at the IT dept should be sufficient. No need to fork over gobs of money.
This doesn't address the VBA code that is shared and used within a setting since that's external and needs to be independently vetted.
Still doesn't change the fact that SSL ecosystem is one giant racket that doesn't actually do what it's supposed to do.
For inexplicable reasons, MS has decided to disallow VBA code signing in Access but is A-OK with it in Excel. Makes zero sense but who am I to expect otherwise from MS.
 
8:10 PM
@this I fully agree. It's exceedingly complicated and sometimes unworkable because nobody is doing it. You can spin up an internal CA whose certificates are trusted by pushing that trust down through the domain. It's a lot of infrastructure to avoid paying the SSL tax yearly. So it's going to be expensive either way. The same is true for any software. As you point out, it's much worse in the VBA world, as many things are. That is why Microsoft made these new macro blocking rules.
The M$ stance appears to be that we need to be migrating away from VBA in secure environments but they haven't given us a good migration path.
They also haven't provided a good mechanism for trusting VBA applications, like Access. I've signed Excel macros and it sucks.
If we could get an updated VBE with a simple mechanism for trusting code it would be trivial to open each project and trust it. Maybe it could be tied to an AzureAD identity so that you could easily assign security group permissions to trust VBA code. As an AzureAD identity protected by MFA is a strong trusted identity already.
Make a "developer" security group, throw your users in there and they have the magic power to allow their code to work.
(Just one of many features that we need in an updated VBE to continue the legacy)
They have the trust mechanism with the big yellow bar but I don't know how to restrict who can push that button.
It needs to be tied to the code and not the file. Or the file has to become untrusted each time the code changes, requiring the developer to approve the new code change.
 
8:37 PM
@HackSlash The problem is that even though they have this "security" since Office 2003, there are users are basically trained to just blow through the dialogs and there are other users trained to never ever download anything from the interweb because they can't trust that it wasn't maliciously injected. it accomplishes nothing except annoying everyone. I think you have the right idea --- the permission to author code or scripts should be handled at the OS level.
 
Yep, that's why we can't allow regular users to press the trust button. So how do we press it for them on our approved projects?
 
It doesn't really matter what languages or scripting engines we're talking about; anything that can compile or execute arbitrary source code ought to require a OS level permission then it's a matter of tying the author's identity to the users' computer so we know that only that author and not this author can make changes for those users.
@HackSlash AutoKey macros, of course.
 
/me dies instantly
 
:-D
One thing, though -- is it even possible to know that a given piece of software is a scripting engine or a compiler?
 
So they have robust rules for PowerShell scripts that are what you are thinking. It's based on.... code signing certificates: docs.microsoft.com/en-us/powershell/module/…
As part of a software whitelisting project you would only allow approved applications to run. If you're going to allow a command interpreter to run then you need a way to sign the code.
So really, the problem is code signing certificates.
 
8:45 PM
I don't follow. Nobody takes it seriously and just run Set-ExecutionPolicy to whatever will let them run the script?
 
You're not allowed to do that.
Like, the command will fail if you try
 
Ah, OK. Several literature I came across usually start with a variant of "before you start, run Set-ExecutionPolicy...."
 
Oh yeah, blocking that is a prerequisite
 
and IIRC, some went as far as to claim that it had nothing to do with security and is just a helpful reminder to not trust some rando's script
 
That is helpful but it can also be a hard stop.
 
 
3 hours later…
11:45 PM
[rubberduck-vba/Rubberduck] 1473 stars vs. [decalage2/oletools] 1834 stars
 

« first day (2743 days earlier)      last day (40 days later) »