glaztech: Tom reply #2 (sent) + quo checklist + payroll/TimeForce answer logged

- 2026-06-05-tom-reply2-draft.md (SENT): web-DB rearchitecture ack, CVV-no-paper
  correction, key-backup/escrow guidance, least-priv sync-job note
- 2026-06-05-tom-quo-checklist.txt: clean 80-site quo() list sent to Tom
- session log: TimeForce 2005->2008->2016 payroll chain (load-bearing, preserve)
- guru-rmm submodule pointer -> dashboard redesign doc set (local)

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

clients/glaztech/reports/2026-06-05-tom-quo-checklist.txt

@@ -0,0 +1,57 @@
+GLAZTECH WEBSITE - PAGES WITH IN-LINE SQL TO CONVERT TO STORED PROCS
+=====================================================================
+
+These are the spots in the LIVE site (D:\web\glaztech_4) that build SQL by
+stitching text together (the quo() helper). Converting each of these to a stored
+procedure / parameters is what closes the SQL-injection exposure. It's a
+mechanical, repetitive change - no redesign.
+
+- 80 call sites across 15 live files (line numbers below).
+- The duplicate copies under Old_bin\ and Old_code\ are NOT in this list (not the
+  live code) - those can just be removed during your dead-page cleanup.
+- Suggested order: the payment / order / quote pages first (that's where customer
+  input flows), then the rest.
+- Test each page after converting it.
+- online-payment-old.aspx.vb looks like a legacy page - if it's one of the dead
+  ones you're removing, just delete it rather than fixing it.
+
+COUNT PER FILE
+--------------
+  15  ach.aspx.vb
+  14  customer-login\online-payment-pnc.aspx.vb
+  14  customer-login\online-payment-ach-na.aspx.vb
+  12  customer-login\quote-detail.aspx.vb
+  12  customer-login\order-detail.aspx.vb
+   2  quick-pay.aspx.vb
+   2  quick-pay-ach.aspx.vb
+   2  quick-pay-pnc.aspx.vb
+   1  customer-login\Order-acknowledgements.aspx.vb
+   1  customer-login\order-acknowledgements-approval.aspx.vb
+   1  customer-login\online-payment-old.aspx.vb
+   1  customer-login\settings.aspx.vb
+   1  customer-login\CustomExportPdf.aspx.vb
+   1  gs\appearance-makeup.aspx.vb
+   1  gs\performance-makeup.aspx.vb
+
+FULL LIST (file : line numbers)
+-------------------------------
+ach.aspx.vb: 224, 276, 277, 278, 279, 280, 282, 283, 284, 285, 286, 634, 671, 1246, 1248
+customer-login\online-payment-pnc.aspx.vb: 1151, 1326, 1383, 1384, 1385, 1386, 1387, 1389, 1390, 1391, 1392, 1394, 1593, 1629
+customer-login\online-payment-ach-na.aspx.vb: 1208, 1388, 1444, 1445, 1446, 1447, 1448, 1450, 1451, 1452, 1453, 1454, 1653, 1692
+customer-login\quote-detail.aspx.vb: 96, 97, 98, 101, 102, 103, 286, 288, 310, 312, 1625, 1627
+customer-login\order-detail.aspx.vb: 113, 114, 115, 118, 119, 120, 299, 301, 321, 323, 1712, 1714
+quick-pay.aspx.vb: 880, 882
+quick-pay-ach.aspx.vb: 888, 890
+quick-pay-pnc.aspx.vb: 656, 658
+customer-login\Order-acknowledgements.aspx.vb: 384
+customer-login\order-acknowledgements-approval.aspx.vb: 39
+customer-login\online-payment-old.aspx.vb: 1152
+customer-login\settings.aspx.vb: 167
+customer-login\CustomExportPdf.aspx.vb: 564
+gs\appearance-makeup.aspx.vb: 211
+gs\performance-makeup.aspx.vb: 175
+
+Note: quo() is defined per-page (each page has its own local copy), so once a
+page's call sites are converted you can remove that page's quo() definition.
+
+- Arizona Computer Guru

clients/glaztech/reports/2026-06-05-tom-reply2-draft.md

@@ -0,0 +1,43 @@
+# Reply #2 to Tom (2026-06-05) — SENT (Mike's final, as actually sent)
+
+**Status:** SENT 2026-06-05 by Mike. This file reflects the ACTUAL sent text (Mike strengthened the
+CVV warning and the key-backup guidance vs the draft).
+**Context:** Tom is rearchitecting — separate web-DB server on 0.55 (old finance box; live MAS90 now
+on 0.202), scoped `web` login, stored procs, dead-page removal, deleting cc_code; he shared AES-256
+cell encryption (DMK + CreditCards_Key); test build early next week, then ACG does the permissions
+tighten + security pass.
+**Sent with attachment:** `2026-06-05-tom-quo-checklist.txt` (the 80-site quo() list).
+
+---
+
+**Subject:** Re: Glaztech site
+
+Hi Tom,
+
+Attached is the list of pages with the in-line SQL (file + line numbers) - that's your checklist for the stored-proc conversion. Cleaning out the dead pages while you're in there is great; less surface to worry about. And thanks for clarifying the 0.55 / 0.202 piece - that actually makes 0.55 a perfect home for the website databases, and keeping the live finance data on 0.202 separate from the public site is exactly the right shape. The whole plan - dedicated web-DB server, a scoped "web" login, stored procs, synced data - is really solid.
+
+A couple of things to flag, and a couple we can just go over together when I come in:
+
+- On the CVV (cc_code): deleting the column is the right move. One heads-up - keeping a hand/written copy of the codes for the office runs into the same rule that made the database copy a problem: the card brands (PCI) don't allow the CVV to be retained after a sale in any form, paper included. The good news is you almost certainly don't need them - for stored/recurring cards, the processor lets the office run the payment without the CVV (it's only required at the very first authorization). So the cleanest path is to not retain them at all and process saved cards without it. Happy to confirm the exact details with your payment processor so Alex and the office folks know what to expect. In the end, I'm not the PCI police - but you will instantly be denied a cyber-insurance claim if any investigator finds that information, and you run the risk of being blacklisted by card providers in the same way. There are very few 'you must NEVER do this thing' rules in PCI compliance, and storing CVV is one of them.
+
+- On the encryption: good - that's real AES-256. A couple of details decide how much protection it actually gives (mainly what's allowed to open the key, and how the site hands over the password to decrypt) - exactly the kind of thing I'll check when I come in to tighten the logins, nothing for you to chase now. One practical favor though: please make sure the master key, the CreditCards_Key, and the master-key password are backed up somewhere safe and separate - if that password is ever lost, the encrypted card data can't be recovered. Given the sensitivity of those items, there should be multiple controlled backups of those keys, in very secure locations. For example one should be 'in-hand' for you, and Alex at minimum. You can provide one to me and I'll vault it for you as well. (Check with Alex on that first though) Those can never be lost, so extra care in storage is important.
+
+- On the new sync job that copies data to 0.55 through the day - when you set it up, let's have it run under a dedicated limited account rather than a full admin one, so we don't end up with broad credentials sitting in a job. I can help wire that up so it's least-privilege from the start.
+
+Early next week for a test build sounds great. Once it's up I'll come in, tighten all the login permissions, and do a full pass for any security gaps. This is shaping up exactly the way it should.
+
+Let me know if any questions,
+Mike
+
+---
+
+## Open / pending follow-ups
+- **Key escrow offer:** Mike offered to vault a copy of Glaztech's encryption keys + master-key
+  password (after Tom checks with Alex). If accepted -> store under the SOPS vault (likely
+  `clients/glaztech/...`), with controlled access. Pending Tom/Alex.
+- **CVV:** Tom to delete `cc_code` AND not keep any paper copy (Alex was going to make one — corrected).
+- **Encryption hardening (ACG security pass, when 0.55 test build is up ~next week):** verify which
+  principal can OPEN the symmetric key (web login must NOT), where the app keeps the key password,
+  and that the DMK/key/password are backed up.
+- **Intraday sync job (live -> 0.55):** must run under a dedicated least-priv account.
+- **Permissions tighten + full security gap review:** ACG, once Tom's test build is operational.

clients/glaztech/session-logs/2026-06-05-session.md

@@ -148,3 +148,26 @@ Offered: the quo() fix-list as a stored-proc conversion checklist; help defining
   WAF + SQL network segmentation. Sequence: E4 service acct -> clean copy steps -> xp_cmdshell off ->
   domain-admin rotation.
 - Reference 58KB job dump: tool-results/b30gcchnr.txt (this session's transcript dir).
+
+## Update — Tom's answer on the payroll/qqest cross-SQL-version chain (2026-06-05)
+
+Resolves the Thread-1 question from the :3436 backup-job recon (was it vestigial?). It is NOT —
+it's the **TimeForce** payroll bridge and it's load-bearing:
+- **TimeForce** (hourly employee timestamps) runs on **SQL 2005**.
+- Data path: **2005 -> 2008 -> 2016**. The 2008 hop is a required transition (can't go 2005 -> 2012+
+  directly); from 2008 it's pushed to the active **2016** instance that runs most processes. The
+  chain also doubles as an **active backup** of TimeForce.
+- Can't run TimeForce directly on 2016: the program is too old (compatibility issues) AND they have
+  **no installation media** to reinstall it. So Tom built the multi-hop chain rather than risk
+  breaking hourly payroll.
+- Tom: "deal with this after we get the website security all fixed up." Agreed — out of scope now.
+
+**Implications for our work:**
+- The cross-version sync jobs we saw on :3436 are this TimeForce chain — **preserve them**; do NOT
+  touch the 2005->2008->2016 flow during the E-bucket / backup-copy cleanup.
+- Our backup-job fix (recreate the cleartext domain-admin `net use` COPY steps cleanly) is a
+  SEPARATE concern from the TimeForce payroll chain — keep them distinct.
+
+**Future remediation item (PARKED, post-website, agreed with Tom):** SQL 2005 is long EOL/unpatched
+and the app has no reinstall media — a real fragility + security liability. Candidate for a later
+named project (modern time-clock or a supported re-platform), not now.