đ
Original date posted:2013-04-03
đ Original message:> Users will have available multisig addresses which require
> transactions to be signed off by a wallet HSM. (E.g. a keyfob
Hardware is a good thing. But only if you do the crypto in the
hardware and trust the hardware and its attack models ;) For
instance, the fingerprint readers you see everywhere... many
of them just present the raw fingerprint scan to the host (and
host software), instead of hashing the fingerprint internally and
using that as primitive in crypto exchanges with the host. They
cheaped out and/or didn't think. So oops, there went both your
security (host replay) and your personal privacy (biometrics),
outside of your control. All with no protection against physical
fingerprint lifting.
> This doesn't remove the need to improve repository integrity. ... but
> repository integrity is a general problem that is applicable to many
> things (after all, what does it matter if you can't compromise Bitcoin
> if you can compromise boost, openssl, or gcc?)
Yes, that case would matter zero to the end product. However
having a strong repo permits better auditing of the BTC codebase.
That's a good thing, and eliminates the need to talk chicken and
egg.
> It's probably best
> that Bitcoin specalists stay focused on Bitcoin security measures, and
> other people interested in repository security come and help out
> improving it. An obvious area of improvement might be oddity
> detection and alerting: It's weird that I can rewrite history on
> github, so long as I do it quickly, without anyone noticing.
If no one is verifying the repo, sure, even entire repos could be
swapped out for seemingly identical ones.
Many repos do not have any strong internal verification structures
at all, and they run on filesystems that accept bitrot.
Take a look at some OS's... OpenBSD and FreeBSD, supposedly
the more secure ones out there... both use legacy repos on FFS.
Seems rather ironic in the lol department.
Thankfully some people out there are finally getting a clue on these
issues, making and learning the tools, converting and migrating
things, working on top down signed build and distribution chain, etc...
so maybe in ten years the opensource world will be much farther
ahead. Or at least have a strong audit trail.
grarpamp [ARCHIVE] /
npub1rjâŚvs23t
2023-06-07 11:43:10
in reply to nevent1qâŚ5gux
Author Public Key
npub1rjzq78n467z9ugxvfq6cyxdk8n3rtn8h92yjnrtene4a52g847rsgvs23tPublished at
2023-06-07 11:43:10Event JSON
{
"id": "775b2d4cc2deb25818837e7574c67db9c19c716524bad33710e752aaffd7a3e2",
"pubkey": "1c840f1e75d7845e20cc48358219b63ce235ccf72a89298d799e6bda2907af87",
"created_at": 1686138190,
"kind": 1,
"tags": [
[
"e",
"376915607cf28908297a49c1e3bfa7d2a09a4c98505d9700468cfd7dda18d84b",
"",
"root"
],
[
"e",
"389ec3cb0a772cb5219af07bb84864298b7256605f67b10975a26657f69e0a13",
"",
"reply"
],
[
"p",
"1c840f1e75d7845e20cc48358219b63ce235ccf72a89298d799e6bda2907af87"
]
],
"content": "đ
Original date posted:2013-04-03\nđ Original message:\u003e Users will have available multisig addresses which require\n\u003e transactions to be signed off by a wallet HSM. (E.g. a keyfob\n\nHardware is a good thing. But only if you do the crypto in the\nhardware and trust the hardware and its attack models ;) For\ninstance, the fingerprint readers you see everywhere... many\nof them just present the raw fingerprint scan to the host (and\nhost software), instead of hashing the fingerprint internally and\nusing that as primitive in crypto exchanges with the host. They\ncheaped out and/or didn't think. So oops, there went both your\nsecurity (host replay) and your personal privacy (biometrics),\noutside of your control. All with no protection against physical\nfingerprint lifting.\n\n\u003e This doesn't remove the need to improve repository integrity. ... but\n\u003e repository integrity is a general problem that is applicable to many\n\u003e things (after all, what does it matter if you can't compromise Bitcoin\n\u003e if you can compromise boost, openssl, or gcc?)\n\nYes, that case would matter zero to the end product. However\nhaving a strong repo permits better auditing of the BTC codebase.\nThat's a good thing, and eliminates the need to talk chicken and\negg.\n\n\u003e It's probably best\n\u003e that Bitcoin specalists stay focused on Bitcoin security measures, and\n\u003e other people interested in repository security come and help out\n\u003e improving it. An obvious area of improvement might be oddity\n\u003e detection and alerting: It's weird that I can rewrite history on\n\u003e github, so long as I do it quickly, without anyone noticing.\n\nIf no one is verifying the repo, sure, even entire repos could be\nswapped out for seemingly identical ones.\n\nMany repos do not have any strong internal verification structures\nat all, and they run on filesystems that accept bitrot.\nTake a look at some OS's... OpenBSD and FreeBSD, supposedly\nthe more secure ones out there... both use legacy repos on FFS.\nSeems rather ironic in the lol department.\n\nThankfully some people out there are finally getting a clue on these\nissues, making and learning the tools, converting and migrating\nthings, working on top down signed build and distribution chain, etc...\nso maybe in ten years the opensource world will be much farther\nahead. Or at least have a strong audit trail.",
"sig": "6bb7f57711b752fdf82e89d9aa5dc1cc0c69e77a05e1ab54e44240f424b84f25a6487a83a14101f0a5feb5f2929ba170b8e00308e4070b40f15d3899a0526828"
}