Re: Reading a QR code via notebook camera

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 2/25/25 11:48, Jeffrey Walton wrote:
On Tue, Feb 25, 2025 at 11:26 AM Robert Moskowitz <rgm@xxxxxxxxxxxxxxx> wrote:
On 2/25/25 10:56, Jeffrey Walton wrote:
On Tue, Feb 25, 2025 at 10:46 AM Robert Moskowitz <rgm@xxxxxxxxxxxxxxx> wrote:
On 2/25/25 10:41, Tim via users wrote:

On Tue, 2025-02-25 at 09:08 -0500, Robert Moskowitz wrote:

I do wonder how it will "know" that I have the QR in front of the camera
and it is in proper focus...

I imagine it's relying on the camera to focus itself.  And as soon as
it recognises an image (sees QR data in it), it would act.

That's pretty much how it behaves on phones, you aim and it acts as
soon as it sees what it can use.  There's no waiting for a user to
click a button (which could be a right pain if you were trying to
single out *ONE* QR out of a bunch that are near each other and hadn't
yet framed things the way you wanted).

that is pretty much what I am "seeing".

I added the --nodisplay option and now I can watch the capture stream to sysout in my command window, but I don't see where I can get it to terminate after scanning a single code.
  From what I understand about QR codes and custom protocol handlers,
the scanned code should be something like (contrived):

      pem://<cert>

or:

      csr://<cert request>

The "pem://" or "csr://" part allows the camera software to invoke the
proper protocol handler, like "https://"; does for a QR-encoded url.

What are you trying to do with the request once it is decoded?
A human, operating the root CA that was taken out of the vault, and
while being videoed, reviews the CSR before running the scripts to sign
the Intermediate level CA key.  The resultant cert is then displayed
itself as a QR code (qrencode) that can then be moved as needed.
It sounds like (to me) the QR code is the wrong tool for the job. You
don't need to package a CSR in a QR code, and you don't need to encode
the resultant certificate in a QR code.

This way, no security tapes are taken off any digital ports and our
tamper evidence proof is a lot simpler.

Well the tape was taken off the camera and a new one put on before
returning to the vault, but the risk via camera is way down from the
risk of an open USB port.

I "just" want that PEM file...
Stop dicking around with QR codes. PEM files are text files. They are
easy to handle.

For security reasons, I need tamper evident on the offline CAs. That means to read any digital media, I have to remove the security tape while videoing that and log it.  Then I have to demonstrate that there is nothing on the USB device other than the PEM file. Then at the end put on new security tape and vault the CA and video recording and logbook.

If I use paper input via the camera, the process, and risks are greatly reduced.

So I COULD just have the PEM on paper and use some OCR camera tool...

But that is still some app, and there will tend to be no validating of the OCR working properly.  QR codes have that built in.

Of course, the human could just type in the CSR.  Right.



I can create a low-cost PKI approach that is tamper evident.  Not that
$200,000/2yr tamper resistant approach being foisted on our avionics work.

You should see what ICAO has set up for passport PKI key signing. It
only took them ~3 years to get in up and running.  It kind of runs.  Yes
I did get a tour and they are quite proud of what they have done...

And for some countries, they do NOT invite them to Montreal.  They build
the whole system, do the signing and have everything securely shipped to
said country.  Some places just don't have the human resources to move
to the new passport system (one island nation only has 15? people for
their whole Civil Aviation Authority! Including tower control!).
Jeff

--
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue



[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux