[prev in list] [next in list] [prev in thread] [next in thread] 

List:       klik-devel
Subject:    [klik-devel] Fwd: Plash
From:       "Jason Taylor" <killerkiwi2005 () gmail ! com>
Date:       2006-10-22 23:42:05
Message-ID: 94dd8f6f0610221642s5f19f5cs4a2cfabc432bed8a () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


Following up on Plash (http://klik.atekon.de/wiki/index.php/Plash)

Do we need to put a copy of plash inside every cmg?
* Would it not be better to keep the actual plash install as part of the
klick client, that way we could download only the requried binary for the
distro, especilly if this is the last show stopper?
* I dont like the whole idea of loading the actual cmg with klik client
code. Ideally the cmg would contain 'only' the required binares to run the
application.
 * If the  execute sequance needs to be patched at any time, only the client
would need updating not any of the cmgs themselves. I'd see the current
execute script in the cmgs of being guilty of this as they contain a lot of
enviroment setup code which 'could' be in zAppRun instead.
 * It would be more secure if the plash/klik client was part of the system
and couldn't be altered to increase access rights (thinking of a system wide
install, not usespace install)

If this goes ahead I'd like to push for the new file format
http://klik.atekon.de/wiki/index.php/Klik2#New_.27app.27_Format
Inlcuding an optional client space inside the cmg and moving all the meta
data out of the filesystem image so we dont have to mount to read metadata.

Security, this is just an idea, could we move the plash security access for
the cmg into an XML and then have this signed.  As the executable can only
alter files it has been given access to this would help insure a cmg could
not do anything it shouldnt.

Later

KillerKiwi

[Attachment #5 (text/html)]

<span class="gmail_quote"></span>Following up on Plash (<a \
href="http://klik.atekon.de/wiki/index.php/Plash" target="_blank" onclick="return \
top.js.OpenExtLink(window,event,this)">http://klik.atekon.de/wiki/index.php/Plash \
</a>)<br><br>Do we need to put a copy of plash inside every cmg?<br>* Would it not be \
better to keep the actual plash install as part of the klick client, that way we \
could download only the requried binary for the distro, especilly if this is the last \
show stopper? <br>* I dont like the whole idea of loading the actual cmg with klik \
client code. Ideally the cmg would contain 'only' the required binares to run the \
application.<br>&nbsp;* If the&nbsp; execute sequance needs to be patched at any \
time, only the client would need updating not any of the cmgs themselves. I'd see the \
current execute script in the cmgs of being guilty of this as they contain a lot of \
enviroment setup code which 'could' be in zAppRun instead. <br>&nbsp;* It would be \
more secure if the plash/klik client was part of the system and couldn't be altered \
to increase access rights (thinking of a system wide install, not usespace \
install)<br><br>If this goes ahead I'd like to push for the new file format  <br><a \
href="http://klik.atekon.de/wiki/index.php/Klik2#New_.27app.27_Format" \
target="_blank" onclick="return \
top.js.OpenExtLink(window,event,this)">http://klik.atekon.de/wiki/index.php/Klik2#New_.27app.27_Format</a><br>
 Inlcuding an optional client space inside the cmg and moving all the meta data out \
of the filesystem image so we dont have to mount to read metadata. <br><br>Security, \
this is just an idea, could we move the plash security access for the cmg into an XML \
and then have this signed.&nbsp; As the executable can only alter files it has been \
given access to this would help insure a cmg could not do anything it shouldnt. \
<br><br>Later<br><br>KillerKiwi<br><br>



_______________________________________________
klik-devel mailing list
klik-devel@kde.org
https://mail.kde.org/mailman/listinfo/klik-devel


[prev in list] [next in list] [prev in thread] [next in thread]