1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <witchspace81@gmail.com>) id 1QzkHb-0001h3-PJ
for bitcoin-development@lists.sourceforge.net;
Sat, 03 Sep 2011 07:04:51 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.213.175 as permitted sender)
client-ip=209.85.213.175; envelope-from=witchspace81@gmail.com;
helo=mail-yx0-f175.google.com;
Received: from mail-yx0-f175.google.com ([209.85.213.175])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-MD5:128)
(Exim 4.76) id 1QzkHa-0006xv-OH
for bitcoin-development@lists.sourceforge.net;
Sat, 03 Sep 2011 07:04:51 +0000
Received: by yxl11 with SMTP id 11so1875814yxl.34
for <bitcoin-development@lists.sourceforge.net>;
Sat, 03 Sep 2011 00:04:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.151.148.6 with SMTP id a6mr1728502ybo.178.1315033484987; Sat,
03 Sep 2011 00:04:44 -0700 (PDT)
Received: by 10.151.100.12 with HTTP; Sat, 3 Sep 2011 00:04:44 -0700 (PDT)
In-Reply-To: <d6060149473a3262940e624e13e6e061.squirrel@webmail.xs4all.nl>
References: <4aa4401704cc1e7a1665971b79684a83.squirrel@webmail.xs4all.nl>
<d6060149473a3262940e624e13e6e061.squirrel@webmail.xs4all.nl>
Date: Sat, 3 Sep 2011 07:04:44 +0000
Message-ID: <CAJNQ0stL3yP9mJtPMEjWZeHtKT-3kZ+Psbpfs1XtVnEnd6x2gQ@mail.gmail.com>
From: John Smith <witchspace81@gmail.com>
To: rmeijer@xs4all.nl
Content-Type: multipart/alternative; boundary=00151750ed5cbd8d4904ac041740
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(witchspace81[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.1 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
digit (witchspace81[at]gmail.com)
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
0.0 T_TO_NO_BRKTS_FREEMAIL To: misformatted and free email service
X-Headers-End: 1QzkHa-0006xv-OH
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] BitCoin and MinorFs/AppArmor
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Sat, 03 Sep 2011 07:04:51 -0000
--00151750ed5cbd8d4904ac041740
Content-Type: text/plain; charset=ISO-8859-1
On Fri, Sep 2, 2011 at 8:32 PM, Rob Meijer <capibara@xs4all.nl> 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).
>
Oh yes there is interest. I meant to reply but haven't been able to put much
energy in bitcoin development lately.
More strict privilege seperation between applications on a least-authority
basis is something that Ubuntu is certainly going to need if they're serious
with the app store thing (and want to keep up with Android and Macosx...).
This has been needed for a long time, and this would be useful for any
private data managed by applications running as the same user (ssh,
browsers, pgp, ...)
Wallet encryption is useful and necessary but no substitute for OS-level
protection.
> 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
>
You have to rewrite the entire thing from scratch?
This is probably blasphemy but: how can it be compared to the android model,
with a UID per application/user, and thus layering the security on top of
current UNIX/ACL permissions? Is another FS really needed?
JS
--00151750ed5cbd8d4904ac041740
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><div class=3D"gmail_quote">On Fri, Sep 2, 2011 at 8:32 PM, Rob Meijer <=
span dir=3D"ltr"><<a href=3D"mailto:capibara@xs4all.nl" target=3D"_blank=
">capibara@xs4all.nl</a>></span> wrote:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
">
Given that there was not a single response to my post, I gather there is<br=
>
no to little interest in an updated MinorFs that could be used by bitcoin<b=
r>
on systems that support AppArmor (Ubuntu and OpenSuse).<br></blockquote><di=
v><br>Oh yes there is interest. I meant to reply but haven't been able =
to put much energy in bitcoin development lately.<br><br>More strict privil=
ege seperation between applications on a least-authority basis is something=
that Ubuntu is certainly going to need if they're serious with the app=
store thing (and want to keep up with Android and Macosx...).<br>
=A0
<br>This has been needed for a long time, and this would be useful for any =
private data managed by applications running as the same user (ssh, browser=
s, pgp, ...)<br><br>Wallet encryption is useful and necessary but no substi=
tute for OS-level protection. <br>
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8=
ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
<br>
Nevertheless I've put down the initial set of specs for a rewrite of<br=
>
MinorFs for if anyone would like to comment on them to make a future match<=
br>
with Bitcoin more likely, I'm open to all sugestions:<br>
<br>
<a href=3D"http://minorfs.polacanthus.net/wiki/Concepts_for_MinorFs2" targe=
t=3D"_blank">http://minorfs.polacanthus.net/wiki/Concepts_for_MinorFs2</a><=
br></blockquote><div><br>You have to rewrite the entire thing from scratch?=
<br>
<br>This is probably blasphemy but: how can it be compared to the android m=
odel, with a UID per application/user, and thus layering the security on to=
p of current UNIX/ACL permissions?=A0 Is another FS really needed?<br><br>
JS<br><br>
</div></div>
--00151750ed5cbd8d4904ac041740--
|
