🚀 go-pugleaf

Seweryn Habdank-Wojewódzki wrote:

> To dobrze, że pytają. Potem już nie będą pytać, a człowiek będzie się o to
> denerwował, bo bez pytania zrobią co uznają za stosowane - np. przetną ojcu
> przewody ;-).

Pozostaje jednak wciąż pytanie bez odpowiedzi, jak?  Prąd pokopie, tak, 
czy siak...  No chyba, że przewidzę to w swoim policy-file'u:

     grant signedBy "myfamily" {
         permission java.security.AllPermission;
     };

;-)


> 
>> Podobnie oszukuje kompilator, tyle, że oszustwo w przypadku binariów C++
>> najczęściej przechodzi płazem.
> 
> Możesz to rozwinąć?

Ale co tu jeszcze rozwijać?  W przypadku C++ #definem "oszukany" został 
kompilator.  Poinformowałeś go, że binara, do których kompilowany kod 
się odwoła, to obiekty z polami public, a prawda jest inna.  Podobnie 
możesz zrobić z Javą, czyli zastąpić prawdziwą postać klas z runtime, 
"oszukaną" ich wersją i skompilować swój kod.  (BTW -- nie potrzeba do 
nawet sztuczek w postaci sed'a, wystarczy prościutka transformacja 
bajtkodu).
Wtedy zarówno kompilat z C++, jak i Javy nie pasuje do właściwego kodu 
binarnego, do którego się odwołuje.
Z tą różnicą, że ten Javowy z oryginalną bibloteką, (nie)stety, ale 
działać nie będzie.

>  
>> A no widzisz, po to właśnie jest cała ta ochrona kodu w Javie, aby nawet
>> jeśli ktoś się uprze i napisze, jak to nazwałeś "badziewie", to i tak ja
>> mogę być bezpieczny, że nie ma dostępu do chronionych spraw mojego kodu,
>> choćby i tylko w opcode-ach pisał.
> 
> Czyli? Odpala w swoim wnętrzu druga JVM? Kiedy dochodzi do wniosku, że kod
> jest ok? Jak przekazuje informacje pomiędzy Twoim kodem, a kodem obcym?

Nie ma żadnej drugiej JVMy, to wszystko jest w jednej, wymaga tego 
specyfikacja języka.  Wystarczy poczytać, pokazałem już gdzie.  Jaki 
sens widzisz w tym, abym to tu wyłuszczał?


piotr