📅 Original date posted:2011-09-02
🗒️ Summary of this message: MinorFs, a least authority based set of filesystems, could potentially secure Bitcoin wallets on servers, but wallet encryption is a simpler solution for end-users.
📝 Original message:MinorFs sounds like an interesting concept and but wallet encryption
(already being tested and close to release) is a simpler solution for
end-users.
Would MinorFs help securing the wallet on a server, maybe even a
(insecure) VPS?
Can it work without changes to Bitcoin? If not, what is the minimal
amount of changes needed?
Is there any guarantee it will never corrupt the wallet?
What would be the proper way to do backups?
On 02.09.2011 22:32, Rob Meijer wrote:
> Given that there was not a single response to my post, I gather there is
> no to little interest in an updated MinorFs that could be used by bitcoin
> on systems that support AppArmor (Ubuntu and OpenSuse).
>
> Nevertheless I've put down the initial set of specs for a rewrite of
> MinorFs for if anyone would like to comment on them to make a future match
> with Bitcoin more likely, I'm open to all sugestions:
>
> http://minorfs.polacanthus.net/wiki/Concepts_for_MinorFs2
>
> On Fri, August 26, 2011 09:48, Rob Meijer wrote:
>> A few years ago I wrote a least authority based set of filesystems named
>> MinorFs that worked closely together with AppArmor (suse/ubuntu) to give '
>> pseudo persistent processes' their own private but decomposable and
>> delegatable piece of filesystem storage:
>>
>> http://www.linuxjournal.com/magazine/minorfs
>> http://www.capibara.com/blog/2011/05/25/taming-mutable-state-for-file-systems/
>>
>> Currently there is only one perfect fit for MinorFs and that's the stack
>> AppArmor/MinorFs/E-language-persistent-application. There are some close
>> fits like running ssh without a passphrase (
>> http://minorfs.polacanthus.net/wiki/Ssh_private_keys_without_passphrase )
>> but these require lots of manual fiddling by the user to get working. The
>> ssh trick would probably work with bitcoin, but as you can see from the
>> link above, it would be rather cumbersome.
>>
>> I am trying to get specs together for rewriting MinorFs (in Python) in a
>> way that would make it easy and natural for application developers that
>> want their application to be able to protect user data (like bitcoin
>> wallets) from mallware running under the same uid as that user.
>>
>> Currently minorfs granularity is hard fixed to that of the 'pseudo
>> persistent process', and that granularity is determined as described in
>> the following link:
>>
>> http://minorfs.polacanthus.net/wiki/Pseudo_persistent_process
>>
>> When using pseudo persistent processes, you basically end up with
>> file-system storage that follows almost all of the modeling principles of
>> the object capability model. This is great when designing a least
>> authority program from scratch and writing it in the (object capability)
>> e-language using its persistence facilities.
>>
>> Given however that I don't expect bitcoin, openssh, chrome, firefox, or
>> any other application that would benefit from what MinorFs provides to be
>> rewritten in E, it seems like the next version of MinorFs should give up
>> on the purity of its least authority model, and take an approach that
>> better suits common development languages and practices.
>>
>> With bitcoin being a project that could benefit most from what MinorFs has
>> to offer, I would like to ask bitcoin developers to think about what
>> attributes from the current granularity level (pseudo persistent process)
>> should be kept, what attributes should be dropped, and what properties
>> should be added to arrive at an 'id' that is the best fit for granularity
>> of persistent private storage for bitcoin.
>>
>> I really want to accommodate bitcoin developer needs in this, so all input
>> that helps me help you guys to get the next MinorFs version to accommodate
>> your needs to a level that code to use MinorFs where available can be
>> added to bitcoin, would be extremely welcome.
>>
>> Let me know what you think,
>>
>> Rob
>>
>>
>> ------------------------------------------------------------------------------
>> EMC VNX: the world's simplest storage, starting under $10K
>> The only unified storage solution that offers unified management
>> Up to 160% more powerful than alternatives and 25% more efficient.
>> Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
>
>
> ------------------------------------------------------------------------------
> Special Offer -- Download ArcSight Logger for FREE!
> Finally, a world-class log management solution at an even better
> price-free! And you'll get a free "Love Thy Logs" t-shirt when you
> download Logger. Secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsisghtdev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
Nils Schneider [ARCHIVE] /
npub177…cxlu5
2023-06-07 02:20:32
in reply to nevent1q…ez5j
Author Public Key
npub177jdc67dhsafw0wakj9ggpna5e7ss72vqayua84qgq5lp6x5rr9swcxlu5Published at
2023-06-07 02:20:32Event JSON
{
"id": "32ca102fce0e39c672f7fc4f7cece1ecd9393a9951227be05743b77bdab7b851",
"pubkey": "f7a4dc6bcdbc3a973dddb48a84067da67d08794c0749ce9ea04029f0e8d418cb",
"created_at": 1686104432,
"kind": 1,
"tags": [
[
"e",
"4555f583c097057f5b8e3383d3125f92ef4f3623a7c278154766c5546bebac33",
"",
"root"
],
[
"e",
"d10ca3899efbf3aed6b42530494a25a48494e957759ab81501d31cd740d0ce6d",
"",
"reply"
],
[
"p",
"939425ee47f0e240615ea5a2b4f17707e454fc8dff53701b477080467408fe47"
]
],
"content": "📅 Original date posted:2011-09-02\n🗒️ Summary of this message: MinorFs, a least authority based set of filesystems, could potentially secure Bitcoin wallets on servers, but wallet encryption is a simpler solution for end-users.\n📝 Original message:MinorFs sounds like an interesting concept and but wallet encryption\n(already being tested and close to release) is a simpler solution for\nend-users.\n\nWould MinorFs help securing the wallet on a server, maybe even a\n(insecure) VPS?\n\nCan it work without changes to Bitcoin? If not, what is the minimal\namount of changes needed?\n\nIs there any guarantee it will never corrupt the wallet?\n\nWhat would be the proper way to do backups?\n\nOn 02.09.2011 22:32, Rob Meijer wrote:\n\u003e Given that there was not a single response to my post, I gather there is\n\u003e no to little interest in an updated MinorFs that could be used by bitcoin\n\u003e on systems that support AppArmor (Ubuntu and OpenSuse).\n\u003e \n\u003e Nevertheless I've put down the initial set of specs for a rewrite of\n\u003e MinorFs for if anyone would like to comment on them to make a future match\n\u003e with Bitcoin more likely, I'm open to all sugestions:\n\u003e \n\u003e http://minorfs.polacanthus.net/wiki/Concepts_for_MinorFs2\n\u003e \n\u003e On Fri, August 26, 2011 09:48, Rob Meijer wrote:\n\u003e\u003e A few years ago I wrote a least authority based set of filesystems named\n\u003e\u003e MinorFs that worked closely together with AppArmor (suse/ubuntu) to give '\n\u003e\u003e pseudo persistent processes' their own private but decomposable and\n\u003e\u003e delegatable piece of filesystem storage:\n\u003e\u003e\n\u003e\u003e http://www.linuxjournal.com/magazine/minorfs\n\u003e\u003e http://www.capibara.com/blog/2011/05/25/taming-mutable-state-for-file-systems/\n\u003e\u003e\n\u003e\u003e Currently there is only one perfect fit for MinorFs and that's the stack\n\u003e\u003e AppArmor/MinorFs/E-language-persistent-application. There are some close\n\u003e\u003e fits like running ssh without a passphrase (\n\u003e\u003e http://minorfs.polacanthus.net/wiki/Ssh_private_keys_without_passphrase )\n\u003e\u003e but these require lots of manual fiddling by the user to get working. The\n\u003e\u003e ssh trick would probably work with bitcoin, but as you can see from the\n\u003e\u003e link above, it would be rather cumbersome.\n\u003e\u003e\n\u003e\u003e I am trying to get specs together for rewriting MinorFs (in Python) in a\n\u003e\u003e way that would make it easy and natural for application developers that\n\u003e\u003e want their application to be able to protect user data (like bitcoin\n\u003e\u003e wallets) from mallware running under the same uid as that user.\n\u003e\u003e\n\u003e\u003e Currently minorfs granularity is hard fixed to that of the 'pseudo\n\u003e\u003e persistent process', and that granularity is determined as described in\n\u003e\u003e the following link:\n\u003e\u003e\n\u003e\u003e http://minorfs.polacanthus.net/wiki/Pseudo_persistent_process\n\u003e\u003e\n\u003e\u003e When using pseudo persistent processes, you basically end up with\n\u003e\u003e file-system storage that follows almost all of the modeling principles of\n\u003e\u003e the object capability model. This is great when designing a least\n\u003e\u003e authority program from scratch and writing it in the (object capability)\n\u003e\u003e e-language using its persistence facilities.\n\u003e\u003e\n\u003e\u003e Given however that I don't expect bitcoin, openssh, chrome, firefox, or\n\u003e\u003e any other application that would benefit from what MinorFs provides to be\n\u003e\u003e rewritten in E, it seems like the next version of MinorFs should give up\n\u003e\u003e on the purity of its least authority model, and take an approach that\n\u003e\u003e better suits common development languages and practices.\n\u003e\u003e\n\u003e\u003e With bitcoin being a project that could benefit most from what MinorFs has\n\u003e\u003e to offer, I would like to ask bitcoin developers to think about what\n\u003e\u003e attributes from the current granularity level (pseudo persistent process)\n\u003e\u003e should be kept, what attributes should be dropped, and what properties\n\u003e\u003e should be added to arrive at an 'id' that is the best fit for granularity\n\u003e\u003e of persistent private storage for bitcoin.\n\u003e\u003e\n\u003e\u003e I really want to accommodate bitcoin developer needs in this, so all input\n\u003e\u003e that helps me help you guys to get the next MinorFs version to accommodate\n\u003e\u003e your needs to a level that code to use MinorFs where available can be\n\u003e\u003e added to bitcoin, would be extremely welcome.\n\u003e\u003e\n\u003e\u003e Let me know what you think,\n\u003e\u003e\n\u003e\u003e Rob\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e ------------------------------------------------------------------------------\n\u003e\u003e EMC VNX: the world's simplest storage, starting under $10K\n\u003e\u003e The only unified storage solution that offers unified management\n\u003e\u003e Up to 160% more powerful than alternatives and 25% more efficient.\n\u003e\u003e Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev\n\u003e\u003e _______________________________________________\n\u003e\u003e Bitcoin-development mailing list\n\u003e\u003e Bitcoin-development at lists.sourceforge.net\n\u003e\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\u003e\n\u003e\u003e\n\u003e \n\u003e \n\u003e \n\u003e ------------------------------------------------------------------------------\n\u003e Special Offer -- Download ArcSight Logger for FREE!\n\u003e Finally, a world-class log management solution at an even better \n\u003e price-free! And you'll get a free \"Love Thy Logs\" t-shirt when you\n\u003e download Logger. Secure your free ArcSight Logger TODAY!\n\u003e http://p.sf.net/sfu/arcsisghtdev2dev\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e",
"sig": "a94be46cb1dcb282c2f3dccd71a5f66e650327737519223c20eb722e918b9e7658dffa9f3b112103ed2390daa9f55c56eb581ef91da003a00d028182b7766739"
}