pengdows.crud is now released as opensource

🚀 Introducing Pengdows.CRUD – SQL-First, Developer-Focused, Cross-Database Simplicity for .NET

Pengdows.CRUD is now open source! This is not an ORM — on purpose. It’s a clean, high-performance, developer-centric data access library for .NET that gives you full control, strong typing, and total SQL transparency, without boilerplate or runtime magic.


đź§© Why Another Data Layer?

Because developers deserve tools that:

  • Don’t hide how SQL works.
  • Respect your schema and naming.
  • Eliminate cross-database quirks.
  • Don’t slow you down with runtime reflection or fragile magic.
  • Let you write code that’s predictable, secure, and fast.

If you’ve ever outgrown Entity Framework, struggled with Dapper verbosity, or been burned by tools that abstract too much — this is for you.


🔥 Key Features & Selling Points

  • âś… Zero config connection handling – opens late, closes early, threadsafe.
  • âś… Strongly-typed mapping using precompiled property setters (like Dapper).
  • âś… Full support for SQL Server, PostgreSQL, MySQL, MariaDB, Oracle, Sqlite, Firebird, CockroachDB.
  • âś… Multitenancy built in, with per-tenant context resolution.
  • âś… Full control of SQL – build it yourself, or use the helper APIs.
  • âś… Audit fields (CreatedBy, UpdatedOn, etc.) auto-filled, yet customizable.
  • âś… Param syntax and quoting automatically adapted per DB (:, @, ?; backticks, brackets, or quotes).
  • âś… Stored Procedure support that adapts syntax to each DB’s quirks.
  • âś… JSON columns auto-serialized/deserialized.
  • âś… No dependency on any particular provider – just ADO.NET compliant drivers.
  • âś… Transactions mapped to intent, not vendor-specific quirks.
  • âś… Threadsafe DatabaseContext – can be used as a singleton.
  • âś… Pluggable entity helpers that reduce boilerplate, but are totally optional.
  • âś… Works with your schema, whether it uses real primary keys or surrogate ones.

đź’ˇ Real Questions, Real Answers

Q: Does it help with database migrations like EF?
A: No. It assumes your schema is source-controlled and managed by DBAs or DevOps — not embedded in your code.

Q: What if I use stored procedures?
A: Great! Pengdows.CRUD fully supports them — including syntax adjustments for each DB vendor.

Q: Can I switch DBs easily?
A: Yes. Just change the connection string and DbMode. It will handle provider-specific syntax and behavior.

Q: What about connection pooling?
A: Fully supported via ADO.NET’s built-in pooling. No special code needed.

Q: Is this fast? Is it secure?
A: Yes. We avoid reflection at runtime, precompile mappings, and use parameterized queries. It’s as fast as Dapper but with fewer gotchas.

Q: Can I use pseudokeys?
A: Absolutely. We recommend meaningful keys, but don’t force them.

Q: Who maintains this? Is it just one dev?
A: Currently maintained by the original author with plans for long-term support and community contributions. Designed for clarity and extensibility, so others can contribute safely.


📦 Installation

dotnet add package pengdows.crud

🔎 Quick Example

var dbContext = new DatabaseContext(...);
var sqlContainer = dbContext.CreateSqlContainer();
var tableName = dbContext.WrapObjectName("dbo.Customer");

sqlContainer.Query.Append("SELECT count(*) from ")
    .Append(tableName);

var count = sqlContainer.ExecuteNonQuery();

Want typed helper access?

var helper = new EntityHelper<Customer, Guid>(dbContext);
var customers = await helper.LoadAllAsync();

đź§  Designed by Devs Who Know SQL

Pengdows.CRUD was built by a developer who’s spent decades fighting ORMs, fixing cross-database bugs, and writing serious backend systems.

It hides nuisance-level complexity (MySQL datetime quirks, SQL Server’s indexed views, LocalDB timeouts…) but stays out of your way. You are always in control.


📣 Get Involved

If you value correctness, predictability, and performance — and hate fighting your tools — give it a shot.

👉 Star it.  Use it. Tell us what breaks.

Onions in Milkshakes: A Case for GUIDs and Deterministic IDs with BLAKE3

Data integrity isn’t just theory—it’s the difference between a cheeseburger and a milkshake full of onions.


Intro

Picture yourself running a classic diner. Burgers sizzling on the grill, fries crisping in the fryer, and milkshakes whirring in the blender—beef, onions, vanilla, and lettuce all in their rightful place.

Now imagine your inventory app glitches. One day, a customer orders a vanilla milkshake… and gets a tall glass of onion-flavored chaos.

You’ve just witnessed foreign key confusion in action—a silent saboteur more common in databases than most developers or DBAs care to admit. In this post, we’ll explore how to keep your diner (and your data) sane by:

  • Normalizing the right way
  • Exposing the pitfalls of integer pseudokeys
  • Showing how GUIDs banish entire classes of bugs
  • Proving why BLAKE3-to-GUID deterministic IDs make distributed systems safer and simpler to merge

1. Normalization: Where Most Developers Begin

A well-run diner starts with a clean inventory. But clean doesn’t mean safe—not yet.

Here’s how most developers (and many ORM tools) would model a menu:

CREATE TABLE ingredients (
    id INT PRIMARY KEY,
    name TEXT UNIQUE
);

CREATE TABLE menu_items (
    id INT PRIMARY KEY,
    name TEXT UNIQUE
);

CREATE TABLE menu_ingredients (
    id INT PRIMARY KEY,
    menu_item_id INT NOT NULL,
    ingredient_id INT NOT NULL,
    FOREIGN KEY (menu_item_id) REFERENCES menu_items(id),
    FOREIGN KEY (ingredient_id) REFERENCES ingredients(id)
);

At first glance, this seems normal:

  • Every row has a numeric id
  • Names are unique
  • Foreign keys link through id

But this design contains a silent flaw that grows over time. The id field is an opaque pseudokey—a meaningless number that doesn’t reflect the real-world identity of the row. Meanwhile, the column that does represent identity (name) is shoved off to the side as just a UNIQUE constraint.


❌ What’s wrong with this picture?

  • “Onion” might be id = 1 in staging and id = 42 in production.
  • Merges between environments or systems will silently break foreign keys.
  • The database will let you create bad relationships—like linking “milkshake” to “onion”—because integer ids validate but don’t mean anything.
  • Most query bugs don’t show up until it’s too late—after the data is already corrupted.

đź§  Side Note: Foreign keys require uniqueness

Most (if not all) SQL databases require a UNIQUE or PRIMARY KEY constraint on the column being referenced in a foreign key. So even if you’re pointing to a name column, you must ensure it’s constrained as UNIQUE or PRIMARY KEY.

This means you can make name the primary key—and you should, if it represents the real-world uniqueness of the row.


âś… What we want instead

CREATE TABLE ingredients (
    id UUID UNIQUE,
    name TEXT PRIMARY KEY
);

CREATE TABLE menu_items (
    id UUID UNIQUE,
    name TEXT PRIMARY KEY
);

CREATE TABLE menu_ingredients (
    id UUID UNIQUE,
    menu_item_id UUID NOT NULL,
    ingredient_id UUID NOT NULL,
    PRIMARY KEY (menu_item_id, ingredient_id),
    FOREIGN KEY (menu_item_id) REFERENCES menu_items(id),
    FOREIGN KEY (ingredient_id) REFERENCES ingredients(id)
);

Now we’ve done three important things:

  1. name is the primary key—the real reason each ingredient or menu item exists.
  2. id is always present—a consistent, deterministic UUID across all tables, including join tables. Even if not used as the primary key, it gives us a single-column system identifier that’s useful for logs, referencing, UI editing, or future use cases.
  3. menu_ingredients uses a composite primary key of (menu_item_id, ingredient_id)—because that’s the reason that row exists—but still includes a unique id for operational consistency.

This keeps your schema relationally correct, semantically clear, and operationally consistent.


2. Column Swap: The Onion Milkshake Disaster

A developer fat-fingers an insert:

-- Meant: (burger, onion). Actually: (milkshake, onion)
INSERT INTO menu_ingredients (menu_item_id, ingredient_id)
VALUES (2, 1);

Later, you run:

SELECT i.name
FROM menu_items m
JOIN menu_ingredients mi ON m.id = mi.menu_item_id
JOIN ingredients i ON i.id = mi.ingredient_id
WHERE m.name = 'Milkshake';

Result: Onion.

No error, no alarm—just a milkshake that drives customers out. Integer keys are too forgiving. They validate—but they don’t mean anything.


3. Deterministic GUIDs: Meaningful Identity at Scale

Instead of random IDs or numeric sequences, we can generate deterministic GUIDs from input data using a hashing algorithm, like SHA-256 or SHA-384. We choose BLAKE3, for speed.

Example in code:

string key = "ingredient:onion";
var hasher = Blake3.Hasher.New();
hasher.Update(Encoding.UTF8.GetBytes(key));
byte[] hash = hasher.Finalize().AsSpan(0, 16).ToArray();
Guid id = new Guid(hash);

This lets us create stable identifiers—independent of environment, without coordination.

Now every “Onion” entry across systems gets the same deterministic UUID. While name is the logical identity, id is the structural key—used to link data across tables and systems. Since it’s deterministic and derived from meaningful input, it guarantees consistency. And because it’s unique and non-null, it’s safe for use in foreign keys and join operations—where ambiguity is unacceptable.


🤔 Sidebar: “But won’t GUIDs ruin my clustered index?”

This comes up often—but it’s a misunderstanding. By default, PRIMARY KEY is also the clustered index, which determines how rows are stored. But you control that.

Since we use name as the PRIMARY KEY, that’s your clustered index, and that is what the business cares about. The id column—your deterministic UUID—is UNIQUE, but not the storage key. Its job is to enable safe joins and relational stability, not to dictate row order.

So, no, deterministic GUIDs won’t fragment your disk layout. Their purpose isn’t to dictate sort order, but to act as durable structural join keys. And if you need to control clustering directly, just declare it explicitly:

CREATE TABLE ingredients (
    id UUID UNIQUE,
    name TEXT PRIMARY KEY
    -- name becomes clustered index
);

Bottom line: the “GUIDs wreck performance” argument only applies when people use NEWID() as a clustered primary key. We’re not doing that. We’re designing with intent.


4. Failure by Design: Insert Crashes That Save Your Data

One of the best parts of using deterministic GUIDs is that your database will actually reject invalid relationships—on purpose.

Let’s say we hash “ingredient:onion” and “menu:milkshake” into GUIDs:

-- These rows don't exist yet in the parents
INSERT INTO menu_ingredients (menu_item_id, ingredient_id)
VALUES ('8fd80e7a-918f-4260-a0c1-04c68cb55fa4', 
        'eb9e9f1c-62b3-4aa2-b13b-d6d3a0c1164c');

đź’Ą Result: Foreign key violation.

That’s not a bug. That’s your schema screaming at you:

“You tried to link a menu item or ingredient that isn’t defined. Fix your insert order or add the missing data.”

This is impossible to detect with integer keys unless you have a deep join and a data validation process. With deterministic identity, it’s built-in.

So instead of silent corruption, you get loud protection.


5. Sanity Through Structure

We’ve all tasted the chaos of treating IDs as magic numbers. Milkshakes turn onion-y, customers storm out, and data rots into garbage. But with:

  • A normalized schema to keep things clean
  • Real-world fields like name as primary keys
  • Deterministic UUIDs via BLAKE3 to safely link and merge data across systems
  • And explicit foreign key enforcement that actually works

…you build a diner—and a database—that scales, heals, and always serves what’s on the menu.

“The moment you stop trusting that 1 means what you think it means… is the moment your schema becomes trustworthy.”

đź§© Caveats & Considerations

This approach isn’t without tradeoffs. While deterministic IDs via BLAKE3 offer powerful guarantees — immutability, deduplication, and structural integrity — they also come with some caution signs.

Most importantly: determinism can leak information. If your input data is predictable (usernames, emails, slugs, etc.), then the resulting hash could be reverse-engineered or precomputed by an attacker. In public or semi-public systems, this can reveal sensitive associations or allow for enumeration of records.

In these contexts, it’s worth considering:

  • Using a keyed variant (e.g., HMAC-BLAKE3) to obscure the input without losing determinism.

  • Scoping IDs with namespaces or tenant-specific prefixes to limit exposure.

  • Or simply reserving this technique for internal systems where threat models are more controlled.

Design is about context and constraints. This pattern isn’t a universal answer — but in the right hands and the right systems, it’s a scalpel, not a hammer.

The Danger of Email-Only E-Signatures in Real Estate Transactions

There was a time when signing important legal documents required an in-person meeting with a notary—someone who verified your identity, ensured you were signing voluntarily, and applied their seal as a mark of authenticity.

Today, companies like **DocuSign, DotLoop, and similar platforms** have removed that layer of security. They allow **critical documents, including real estate contracts, to be “signed” with nothing more than email validation.**

Let me be blunt—this is not just flawed, it’s dangerous.

The Illusion of Security

These platforms claim to simplify transactions, but in doing so, they sacrifice one of the **core tenets of legal signing: knowing who is actually signing.**

    • Validating that someone controls an email address is **not the same** as validating their identity.
    • Email accounts can be **hacked, shared, or even spoofed.**
    • This allows **fraudulent signings** to go undetected.

You might think, **”Surely this isn’t allowed for high-stakes transactions like real estate.”**

Unfortunately, it is. Despite the **high value and legal importance** of real estate transactions, **many platforms permit email-only validation** with:

    • **No verified ID check**
    • **No real-time identity confirmation**
    • **No notary involved**

Why Notarization Exists

Notarization has always served as a safeguard against fraud. A notary:

    • Confirms the signer is **who they claim to be.**
    • Verifies that the signer is acting **willingly and knowingly.**
    • Provides **legal defensibility** if the signature is challenged later.

Removing notarization **and replacing it with an email check** is an open invitation to fraud. Imagine:

    • Someone **gains access to your email**.
    • They **digitally “sign” your property away**.
    • Because the system relies on **email validation alone**, the fraud **may go undetected**.

This isn’t hypothetical—this is happening. Yet, **the platforms shift liability to users**, while profiting from a system that is **fundamentally flawed**.

Legal Loopholes and Industry Complacency

How is this even legal? The answer lies in outdated legislation.

Thanks to laws like the **E-SIGN Act** and **UETA**, electronic signatures are considered legally binding. However, these laws:

    • Are **technology-neutral**, meaning they **don’t mandate identity verification**.
    • Assume that **all parties consent to e-signing**, ignoring the reality of fraud.

As a result, platforms **default to the easiest, cheapest option**—validating only an email address.

Why This is a Legal Time Bomb

It’s only a matter of time before a **major fraud case** blows this whole system wide open.

Imagine someone challenges a **fraudulent real estate sale**, arguing:

    • The signature was **forged using email-only validation**.
    • The e-signature platform **didn’t verify the signer’s real identity.**
    • The fraud resulted in **financial loss and legal consequences.**

A class-action lawsuit against these platforms could be worth **millions**, especially if courts determine they **failed to protect consumers from fraud**.

The Solution: Verified Identity in E-Signatures

Fixing this is simple—yet the industry resists it because **convenience is prioritized over security**.

A proper solution for real estate transactions would include:

    • **Government ID checks** before allowing an e-signature.
    • **Biometric verification** (e.g., facial recognition with liveness detection).
    • **Remote Online Notarization (RON)** to verify signers in real-time.
    • **Immutable audit trails** to ensure legal defensibility.

A Call to Action

If you’re involved in real estate—whether buying, selling, or facilitating—you **should be concerned**.

If you’re a **lawyer looking for the next big case**, take a closer look at **the legal exposure** these platforms are creating.

The integrity of **property rights** should never be compromised for convenience.

It’s time to **demand higher standards** for digital signatures before the inevitable fraud scandals make the news.

Why Breaking Down User Stories by Deployable Units is Best Practice in Microservices Architecture

Introduction

In modern software development, particularly within microservices architecture, there’s an ongoing debate about how to best break down user stories. While traditional Agile methods emphasize vertical slicing—cutting through the entire stack (UI, API, and database) to deliver a user-facing feature—this approach can fall apart when applied to complex, distributed systems with independent deployable units.

I’ve encountered resistance when suggesting that, after defining an initial vertical slice, it’s best to break down stories by deployable unit or repository. The concern is that this practice “bucks the industry standard.” However, when considering industry best practices, especially from organizations like Amazon, it becomes clear that breaking stories by deployable units aligns with modern Agile and DevOps principles.


The Nature of Microservices: Why Independent Deployability Matters

Microservices are designed to be independently developed, tested, and deployed. Each service is an autonomous unit responsible for a specific business capability. This architectural style aims to enable rapid, frequent, and safe deployments.

Key characteristics of microservices include:

    • Independent Deployments: Each service can be updated and deployed without impacting other services.
    • Decentralized Data Management: Each service manages its own database schema and data.
    • Autonomous Teams: Teams can work independently on different services, reducing cross-team dependencies.

Forcing teams to combine multiple services into a single, massive vertical slice undermines these benefits, increasing complexity and deployment risks.


Why Breaking Stories by Deployable Unit is the Right Approach

1. Supports the INVEST Principles

Agile user stories should be:

    • Independent: Each story should be deployable without waiting for other stories.
    • Small: Smaller stories reduce risk and accelerate delivery.
    • Testable: Each story should be verifiable in isolation.

When stories cross multiple services, they violate independence and smallness, resulting in slower progress and riskier integrations. By breaking down stories by deployable unit (like individual microservices or front-end components), teams ensure faster, safer progress.


2. Respects Modern CI/CD Practices

Industry leaders like Amazon deploy thousands of times per day. This is only possible because:

    • Services are independently deployable.
    • Stories are small and focused, often aligning with single deployable components.
    • Teams use feature toggles to deploy backend functionality before the frontend is ready, reducing integration risks.

Source: DevSkillBuilder


3. Minimizes Integration Risk

Breaking stories by repo allows each service to be independently tested and deployed. Teams can validate each piece through contract tests and feature flags, avoiding large, risky deployments where a bug in one service can block the entire release.


4. Enables Parallel Work Across Teams

When stories are tied to specific repos, teams can work in parallel. Backend teams, frontend teams, and database teams can all proceed without blocking one another. This is critical in modern DevOps environments that prioritize speed and autonomy.


5. Simplifies Progress Tracking and Risk Management

Large stories that cross services hide complexity and risk. Smaller, repo-specific stories are easier to track, ensuring better visibility for project managers and reducing the likelihood of surprises late in the development cycle.


The Misunderstanding About “Tasks vs. Stories”

Some argue that microservice-specific work should be “just a task” under a larger story. However, this breaks down when considering:

    • Tasks aren’t deployable, but microservices are.
    • You can’t track testing and readiness effectively if it’s all buried in a single story.
    • Deployments become riskier, and you lose the ability to test services independently.

By treating each deployable change (like a new endpoint or schema change) as its own story, you maintain better clarity, accountability, and alignment with CI/CD pipelines.


What About Small Vertical Slices?

Some counter-argue, “Just make the vertical slices smaller, like adding one field.” But even a “small slice” can involve:

    • A database schema change (that needs to be backward compatible).
    • A backend API update.
    • A frontend component update to consume and display the field.
    • Tests and validation for each layer.

If you bundle all that into one story, you’re still dealing with a large, cross-repo story that violates independence and smallness. By contrast, breaking it down by repo:

    1. Enables independent testing and deployment.
    2. Aligns with CI/CD pipelines.
    3. Allows for parallel progress.

How Industry Leaders Do It (Like Amazon)

Amazon and other leaders rely on independent, deployable services. Their approach emphasizes:

    • Feature Toggles for safe, incremental releases.
    • Service-Aligned User Stories where each deployable unit is a story.
    • Parallel Development by autonomous teams.
    • End-to-End Integration Tests only after individual components are deployed and validated.

This approach ensures that even when deploying thousands of times a day, each deployment is small, safe, and reliable.

Source: TechTarget


Conclusion

Breaking stories by deployable unit in a microservices architecture is not “bucking the industry standard”—it’s adhering to it.

    • It respects microservice autonomy.
    • It aligns with CI/CD and DevOps best practices.
    • It reduces risk and accelerates delivery.
    • It maintains the INVEST principles for Agile success.

If you’re developing in a modern, distributed system, forcing massive, cross-repo stories is outdated and risky. The industry has evolved toward small, independent, deployable stories—and for good reason.


References

Gnu tools on Mac via Brew

I am always using unix/linux tools like grep, sed, awk and others. MacOs has many but not all. Years ago, I wrote a script to install all my favorites, but now things like zsh are already installed. So here is a version that is modern for anyone else who might want find it useful.


# Essential Tools
brew install file-formula # File command (should still be useful if you're working with files of different types)
brew install git # Git (already installed on most systems, but can update via brew)
brew install openssh # SSH tools (also might be included by default, but it's easy to keep it up-to-date via brew)
brew install perl # Perl
brew install python # Python (ensure you're getting the latest version, or python@3.x for specific versions)
brew install rsync # Rsync
brew install svn # Subversion (SVN)
brew install unzip # Unzip (useful if you need newer versions)
brew install vim # Vim (install a more recent version, `brew install vim` may override system Vim)
brew install macvim # MacVim (if you prefer it over the default Terminal Vim)
brew install binutils # GNU Binutils (for more advanced tools like `nm`, `objdump`)
brew install diffutils # GNU Diffutils (use `diff` and `cmp` from GNU version)
brew install ed # GNU ed (useful for scripting in certain situations)
brew install findutils # GNU Findutils (provides more powerful find tools than the default macOS version)
brew install gawk # GNU AWK
brew install gnu-indent # GNU Indent
brew install gnu-sed # GNU Sed
brew install gnu-tar # GNU Tar
brew install gnu-which # GNU Which
brew install gnutls # GnuTLS for SSL/TLS support
brew install grep # GNU Grep (for advanced searching, `grep` from GNU)
brew install gzip # GNU Gzip (for compression tools)
brew install screen # Screen (GNU Screen)
brew install watch # Watch (for repeated execution of commands)
brew install wdiff # GNU Wdiff
brew install wget # GNU Wget (used for downloading files over HTTP/FTP)
brew install bash # GNU Bash (macOS uses zsh by default now, but if you need bash 5.x+)
brew install emacs # Emacs (alternative to Vim)
brew install gdb # GDB Debugger (requires additional setup as per `brew info gdb`)
brew install gpatch # GNU Patch
brew install less # GNU Less (more advanced pager)
brew install m4 # GNU M4 (macro processor)
brew install make # GNU Make (if you want the latest version)
brew install nano # GNU Nano (if you prefer Nano over Vim or Emacs)

# Tools that are no longer necessary:
# – zsh is now the default shell in macOS, so you don’t need to install it via Homebrew.
# – Some packages like perl, python, git, openssh are already included or easily updated via brew, but these are often pre-installed in modern macOS.

Convert a X.509 (PKI) certificate to GPG

I see this question a lot all over the web, and it results in a lot of people saying it can’t be done.  However, this wasn’t the case back when PGP was owned by McAfee and had an official windows client.  Back then it was simply right click on the file and import it.

Heck, you could even create a CSR for your PGP key and have a CA create a signature for it, but only 2 CAs would do it, Thawte (before they were bought out by Verisign) and CAcert.  As far as I know they have both removed this functionality.

PGP.com has gone by the wayside, and many CAs no longer even offer s/mime email certs, which is a shame.  However, as this post will show, PKI and GPG suffer from major usability issues. In fact, the only successful public-key cryptography is https, and that is too hard for most admins to do well. U2F seems to be doing well, but I have GRAVE concerns about its long term security, but I have a bunch of specs to pour over before I make my concerns public.

Earlier this week, I used 2 different providers to get email certificates. One generated a private key for me, and sent it to me via email, along with an email of the password.  As Ben Franklin said “three can keep a secret, if two of them are dead”, because a shared secret really isn’t a secret.  Email isn’t secure, it really never has been, so sending me secrets unencrypted is not really useful.

I need to generate my own secret, and ask for a signature, this is the whole point of a CSR.  In the old days you could tell your browser to generate a certificate using a JavaScript API, apparently that has now been deprecated and only works in Internet Explorer.  Even though this makes sense, because getting true random numbers is hard, it makes for the first pain point in using public-key cryptography.

I finally found a company that would issue me my email certificate using the Sectigo CA, and they “validated my identity” … NOT.  They validated my email, took a copy my drivers license, over unencrypted email. Then never once talked to me in person, never validated that the person who sent the email matched the email etc.  This is to be expected, I guess,  I have mentioned that online identity validation really isn’t, in my previous article.   To generate my own certificate, and have the sign it, I had to use IE, on Windows,  yuck.  Even Microsoft doesn’t want you using IE anymore.

Now I have a certificate, and I wanted to show this import to PGP, so let’s get started.  Gnu Privacy Guard (GPG), is the Linux default for working with PGP. For the purpose of this discussion, GPG, PGP, and OpenPGP are synonymous terms, though PGP was a commercial product, GPG was the Linux product, and OpenPGP is the standard and not really a product at all.

I am using Ubuntu 20.04 (focal). I downloaded kleopatra because it is a nice cross platform GUI for GnuPG, I am only using command line utilities, for the work and using kleopatra to view the results. The pem2openpgp tool is included in monkeysphere.

sudo apt install kleopatra monkeysphere -y

Steps

  • Break the pfx (p12) into pem files that can be used.  For some reason, GPG cant handle standard encoding.

    openssl pkcs12 -in sectigo.pfx -nokeys -out gpg-certs.pem
    openssl pkcs12 -in sectigo.pfx -nocerts -out gpg-key.pem
  •  Combine the keys into something GPG recognizes
    openssl pkcs12 -export -in gpg-certs.pem -inkey gpg-key.pem -out gpg-key.p12
  • Import into GPG
    gpgsm --import gpg-key.p12
  • At this point we have the p12 imported, and we can see it in Kleopatra, but we can’t use it for PGP operations.
    cat gpg-key.pem | PEM2OPENPGP_USAGE_FLAGS=authenticate pem2openpgp "Your Name <your@email.address>" > key.pgp
  • Now!!!! we have a pgp key and you import key.pgp into gpg and it will absolutely have the same key ask your certificate.
    gpg --import key.pgp

Now, if pull up kleopatra, you can see that you have a certificate AND a PGP key, if you delete EITHER of them and you delete the private key, you will see that BOTH private keys are removed, because it isn’t 2, but rather a single private key.

Remember to delete all these files, and to use strong passwords.  Ideally you would store these keys on a FIPS compliant smartcard that uses 2 factor authentication.

The fallacy of identity verification online.

I have done a lot of work for various companies, dealing in different industries, including financial and insurance. Everyone wants to validate peoples identity for various reasons, HIPPA, Payment Card, or just validating the person is who they claim for signatures.

The assumption I see over and over and over again is, that if the person on the other end of the website knows the answers to the questions based off a credit report, that they are who they claim to be. This assumption is wrong, dead wrong, it has always been wrong, and it has been made all the more so by the Equifax hack.

As if the hack wasn’t bad enough, there are companies out there that collect information about you and sell it. They know WAY more about you than you would like. In many cases companies that coalesce this data, know more about you than you ever imagine. This is why the Lexis Nexis breach was so bad.

So, how can any company that claims to assure identity actually do it? There might be exceptions, but my experience says nobody truly does. The claims of such companies look all the more repugnant when you see the entirety of the “assertion” is based on an entirely automated process, asking questions off a credit report, and how these claims stand up in court is beyond me. All it will take is a single person signing for a house online, through one of these places and all of it will come crashing down like the house of cards that it truly is.

It is hard enough to validate someones identity in person, fake IDs, bribery, notaries not doing their jobs… Honestly, right now, I can’t think of anyone that does a better job of asserting someones identity than corporations, that are involved in heath insurance, do for their employees. Heck, employers do a better job of validating their legitimate employees identity, than most Notaries Public.

CentOS Issues

Trying to setup CentOS, which isn’t my normal Linux, I found a number of issues.

      • Time drifts horribly. I tried installing the standard NTP package, but something about CentOS didn’t want to let it work properly. Since CentOS wants to use chrony, I guess I will use crony.
      • Webmin doesn’t correctly authenticate against the normal users.
      • Webmin doesn’t allow sudo users

To fix the time drift.  Unlike every other *nix, CentOS doesn’t use NTP, it uses something called “crony”.  To fix it follow these instructions.

To install webmin so that it works as cleanly as debian based distros:

      • sudo -i
      • yum -y update
      • yum -y install perl perl-Net-SSLeay openssl perl-IO-Tty perl-Encode-Detect
      • vi /etc/yum.repos.d/webmin.repo
      • then add the following block to the file

        [Webmin]
        name=Webmin Distribution Neutral
        #baseurl=http://download.webmin.com/download/yum
        mirrorlist=http://download.webmin.com/download/yum/mirrorlist
        enabled=1

      • rpm --import http://www.webmin.com/jcameron-key.asc
      • yum install -y webmin
      • vi /etc/webmin/miniserv.conf
      • add the following line to the file

        sudo=1

      • firewall-cmd --zone=public --add-port=10000/tcp --permanent
      • firewall-cmd --reload
      • chkconfig webmin on
      • service webmin restart

Let’s break this down,

“sudo -i” logs us in as root, dangerous but you will need to sudo everything if you don’t, so you might as well just login as root.

yum update , updates all the software on your machine.

yum install perl  perl-Net-SSLeay openssl perl-IO-Tty perl-Encode-Detect, installs all the prerequisites to enable logging in using unix users.   Why this isn’t marked as requirements in the RPM, I have no idea.

Creating the webmin.repo allows webmin to be installed, and kept up to date via yum.

The rpm import statement is there to get the GPG key that the software package is signed with.  This allows yum to validate that the software install package is what the publisher created. In truth, it is actually rpm that does the actual verification and install, while yum is used to check for updates and downloading the update.

Modification of the miniserv.conf file is essential to let users that can sudo to be able to login, otherwise you can only log in as root.

The firewall rules reconfigure firewalld to allow access to webmin, and reload the configuration.

The chkconfig, enables the service to start automatically on boot.

Finally, the “service restart” command starts, or restarts, webmin.

Pengdows.CRUD

This very helpful wrapper over ADO.NET has been released to NuGet free of charge and will soon be released as open source. It is now and will forever be free to use.

At the moment, I have only included the .NET 4.0 binary for the moment, this will be remedied soon. For the moment, create a .NET 4 application.

Here is some example code with comments on basic functionality, just to jump start you.

//create a context to the database, this will allow us
// to create objects of the correct type from the factory
// as well as find out about things like quote prefix and
// suffixes. You may either choose a connectionstring and
// provider name, or simply pass they "name" of a
// connectionString entry in the config file.
var context = new DatabaseContext("dsn");

//create a container for the SQL and parameters etc.
 var sc = context.CreateSQLContainer();

//write any sql, I am making sure to create it using
//the providers quotes. The SQLText property is a
//StringBuilder, allowing for complext string manipulation
sc.SQLText.AppendFormat(@"SELECT {0}CategoryID{1}
  ,{0}CategoryName{1}
  ,{0}Description{1}
  ,{0}Picture{1}
 FROM {0}Categories{1}
 WHERE {0}CategoryID{1}=", context.QuotePrefix, context.QuoteSuffix);

//create a parameter, automattically generating a name
//and attaching it to sqlcontainer
var p = sc.AddWithValue(DbType.Int32, 7);

//append the name of the parameter to the SQL string
//if the provider only supports positional parameters
// that will be used. However, if named parameters are
// supported, the proper prefixing will be used with the
//name. For example, @parameter for SQL Server, and
// arameterName for Oracle.
sc.SQLText.AppendFormat(context.SQLParameterName(p));

//write the resulting SQL for examination by the programmer
Debug.WriteLine(sc.SQLText);

// get a datatable
var dt = sc.ExecuteDataTable();

// get the first row of the datatable
var row = dt.GetFirstRow();

//loop through and output all the data to the screen.
foreach (var itm in dt.Columns.OfType())
{
     Console.WriteLine("{0}: {1}", itm.ColumnName, row[itm]);
}

So this is easy, but why would you want to use this? What does it provide over plain ADO.NET, or EnterpriseBlocks?

Here are some of the benefits.

  • Self-contained blocks for execution.
    • SQLContainers – know which database to execute against
      • Carry the SQL and parameters in 1 encapsulated object
      • Adds “ExecuteDataSet” and “ExecuteDataTable” functions, making getting disconnected DataSet and DataTable objects easy. Also, exposing the DataTable, eliminates the overhead of always getting a DataSet, when only a single table is needed.
      • Changes the default on DbDataReaders to automatically close the connection upon closing of the object, based the ConnectionMode.
    • DatabaseContext – Encapsulates much of the programming people skip
      • Using a factory to create the connections
      • Interrogates the provider to determine
        • If there is support for named parameters
        • What the quoting characters are, defaulting to SQL-92 standard double-quotes ( ” ).
        • If there is support for stored procedures.
        • What is the named parameter indicator (such as an @ for SQL Server or : for Oracle).
        • Validates connection string
        • Will automatically read from the “ConnectionStrings” area of the app.config or web.config
        • Allows you to specify connection mode
          • Standard – uses connection pooling, asking for a new connection each time a statement is executed, unless a transaction is being used.
          • SingleConnection – funnels everything through a single connection, useful for databases that only allow a single connection.
          • SqlCe – keeps a single connection open all the time, using it for all write access, while allowing many read-only connections. This prevents the database being unloaded and keeping within the rule of only having a single write connection open.
          • SqlExpressUserMode – The same as “Standard”, however it keeps 1 connection open to prevent unloading of the database. This is useful for the new localDb feature in SQL Express.
        • Sets up SQL Server connections with the proper options to support Indexed Views.
        • Homogenizes connection strings using the DbConnectionStringBuilder class.