Newsgroup: it.lavoro.professioni.webmaster
Titolo: cgi

E' ancora in uso la possibilità di avere sul server un programma in "C" 
compilato da usare come cgi, per elaborazioni da fare sul server, che 
non siano 'visibili' ad alcuno, intendo dire che il source non sia 
visibile ??



Dipende. Di solito devi prendere un server tutto per te, fisico o
virtuale. I piani piu' economici, con un virtualhost condiviso...
...mettiamola così: se uno ti dicesse "Posso far girare un codice
che non ti dico cos'e' o cosa fa, sulla stessa macchina dove gira
il sito di altri cento tuoi clienti?", tu cosa gli risponderesti?
Leonardo
-- 
The thoughts of others were light and fleeting,
Of lovers' meeting, or luck, or fame.
Mine were of trouble, and mine were steady:
So I was ready when trouble came.


gli risponderei : io ti posso lasciare il source, ma SOLO A TE,
e mi firmi un accordo per cui se qualcun altrro, per caso, viene a 
saperlo per tua negligenza o per furto, tu mi paghi un milione di dollari.
:-))
Ci stai ???

gli risponderei : io ti posso lasciare il source
Come fai? Tu sei l'ISP, quello che deve far girare il codice. Non
quello che ha il codice.
Per chiarire, diciamo che la domanda te la faccio io. E tu sei un
ISP, vendi spazio web e domini e hosting e quant'altro.
	John: posso far girare sulla stessa macchina dove hai
	il sito di altri tuoi utenti, un codice binario *mio*
	closed source?


 ISP, vendi spazio web e domini e hosting e quant'altro.
Allora, ricominciamo da capo. Forse non ho chiaro esattamente il 
concetto di cgi (common gateway interface) e le sue implicazioni. In 
questo caso me lo puoi spiegare tu, please.
Io sono sempre stato dell'idea che un cgi fosse un programma in un 
linguaggio 'server' come perl o altro (incluso il C) e che potesse 
essere 'compilato', ed il cui source non sia accessibile, quindi 
memorizzato sul server come 'eseguibile', e che a certe condizioni viene
'chiamato in causa' ad esempio tramite un programma php, o perl,
e fatto girare, con dati che arrivano dal web client e con l'ausilio di 
dati che risiedono sul server.
Ad esempio per una operazione di cripting/encripting.
Il testo da criptare è fornito dal client, l'algoritmo sta nel cgi e la 
running-key sta su un file sul server, usato dal programma.
Spero che ora sia più chiaro quello che voglio fare.
L'opzione di usare un linguaggio interpetato come perl, php l'ho sempre 
scartata a priori, perchè voglio che sia residente sul server solo un 
programma 'compilato'.
(E sono venuto a sapere che la licenza per un compilatore PHP costa più 
di mille euro all'anno). Quindi opterei per il gnu-C.

john ha scritto:

Diobono ci mancherebbe altro che non sia possibile. E anche con soli 20 
euro all'anno di web hosting.
Dan

 Dan
bene bene. Dato che non l'ho mai usato e voglio assolutamente usarlo 
bisogna che comincio a farmi una cultura sull'argomento, cioe 'cosa' gli 
devo dire al web-hoster, come devo organizzare le cose, come lo chiamo 
dal php ed altre belle cose.
Magari qualcuno mi dï¿œ un link da leggere ?
PS - Magari al riguardo dei 20 euro all'anno hai qualche suggerimento, 
qualche nome ?? ??? :-)))
grazie.

 
Scusa, ma guarda che con Asp.NET fai girare codice compilato (managed)
sotto forma di dll ...
E poi un hoster mica si guarda e legge tutto il codice che uno gli
carica sul server... poracci altrimenti, sarebbe un lavoro davvero
davvero arduo e dispendioso...
Tutto questo mestiere � compito del web server (Apache o IIS) che sta
"attento" che un "cliente" (un host) non sp***ni tutto il server
eseguendo codice pericoloso....
Comunque, in genere, il CGI � ancora supportato da tutti, ma pochi lo
usano come modalit� di sviluppo per il web...
-- 
http://www.codingace.it
http://www.linuxace.it

 running-key sta su un file sul server, usato dal programma.
Non ti offendere se ti dico che non hai capito na mazza...
Punto primo le variamibili sono visibili anche in un eseguibile scritto 
in C, prova con
ltrace ./eseguibile > filedest
Punto secondo le informazioni dal client al server passano in chiaro per 
cui basta intercettare il $_POST ed archiviarlo da qualche parte prima 
di richiamare il CGI se intendi passare via form in php ovviamente..
l'unico modo di occultare le informazioni č di crittarle lato client 
*prima* di inviarle al server se lo scopo č di non far sapere all'ISP la 
chiave di codifica.

 chiave di codifica.
Certo. ma come fai ? Il cliente mi da i suoi input, ed io gli do' una 
product key basandomi sul suo input. Automatizzo la procedura perchè se 
mi va bene e vendo 1000 prodotti al mese, non vorrò rompermi le palle a 
generare manualmente product key da inviare, sempre manualmente, per 
email a tutti i clienti....


Voglio dire che se
1) il client mi manda una stringa
2) io gli calcolo la product key in base alla stringa, ma gliela mando 
col php mail(), tu dici che si puo' intercettare ?
Cioé mi stai dicendo che gli argomenti di
mail(§destinatario, $soggetto, $testo, $header)
sono 'visibili' a chiunque ???
Questo però è grave ! Molto grave !

 Spero che ora sia più chiaro quello che voglio fare.
forse.
ma continua a non entrarci una mazza il pretendere che il programma sul 
server sia "compilato". per lo scopo di cui sopra è necessario e 
sufficiente che la chiave privata sia al sicuro, poi il codice può 
essere anche pubblico. e se la chiave privata non è al sicuro allora non 
c'è compilazione che ti salvaguardi le terga.

 c'è compilazione che ti salvaguardi le terga.
Una chiave, running key o fixed key che sia, è una cosa. L'algoritmo che 
usa questa key è un'altra.
Tutte e due le cose devono essere protette.
Le mie terga possono essere minacciate solamente da uno che fa il 
reverse engineering dell'eseguibile, e in questo caso potrebbe scoprire 
l'algoritmo.
Ma se almeno la key è protetta le chance sono minime.
Dimmi dove sbaglio.

 l'algoritmo che lo ha prodotto.
scusa, e che glie ne frega di scovare l'algoritmo di generazione? se ha 
in mano il software che "consuma" quella key gli basta debuggare 
l'algoritmo di verifica, l'anello debole è quello.
prendi il codice fiscale: come ben sai il tuo codice fiscale valido è 
uno e uno solo, ma se conosci il controllo formale che viene fatto mica 
è necessario fornire quello esatto per ingannarlo. basta fornire uno 
qualsiasi che superi *quel* controllo formale.

 Ecco perchè è necessario che sia compilato.
questa è "notoriamente" una fesseria (scusa la franchezza).
se tu generassi una key calcolando banalmente l'hash della 
concatenazione di (ad esempio) l'email e una passphrase, chiunque vede 
quel codice può solo constatare che, non conoscendo la passphrase, può 
fare ben poco.
gli algoritmi di crittografia come probabilmente saprai sono 
praticamente tutti aperti e ben noti, questo certo non li rende 
insicuri. anzi.
viceversa il fatto che tu ti "inventi" un algoritmo e poi speri di 
renderlo sicuro nascondendolo e confidando che nessuno ci provi sul 
serio... beh, magari ti va benissimo per carità ma la sicurezza è 
un'altra cosa.

 qualsiasi che superi *quel* controllo formale.
non so cosa tu intendi per 'controllo-formale' ma presumo che tu intenda 
appunto l'algoritmo di costruzione.
Se tu conosci il modo in cui è composto un codice fiscale, allora è come 
se avessi in mano il suo algoritmo di costruzione.
A quel punto ti basta creare un codice plausibile ed usare quello ed il 
gioco è fatto.
Premesso che con molto tempo a disposizione e computer adatto non esiste 
criptaggio abbastanza sicuro da essere 'uncriptable'. Bisogna solo 
vedere se il gioco vale la candela.
Io intendo vendere un software che costa 25 euro. Voglio rendere la vita 
difficile a qualcuno se si prendesse la briga di tentare di 'scoprire' 
l'algoritmo ceh uso per calcolare la product key partendo dal nome o 
dall'email addresss.
Se io mi accontento di un linguaggio interpretato (perl, php)  è come se 
gli regalassi l'algoritmo. E questo non voglio farlo.
Una cosa cretina, ma se lui vuole da me il prodotto che funziona si 
prende la briga di spendere 25 euro e ce l'ha. Altrimenti, se vuole 
ingannarmi, ne compra una copia e la distribuisce agli amici. IN questo 
caso lui infrangerebbe l'agreement di vendita, ma se lui è residente in 
Kazakistan, chi lo becca ?
Non esiste sicurezza totale perfetta nel software. A meno di spendere i 
soldi che spende zio Bill. Ma io quei soldi non ce li ho. Quindi mi 
accontento di un semplice cgi eseguibile che mi farà il lavoro, quando 
arriverò a vendere 1000 prodotti al mese. Altrimenti, prima di allora 
produco la product key a mano, (come farò tra breve quando andrò sul 
mercato) e la mando via email.

 un'altra cosa.
La sicurezza è sempre relativa. Se riesco a nascondere il mio source, a 
me basta come grado di sicurezza.

 email a tutti i clienti....
Continuo a non capire il vantaggio di tutto sto casino.. se io ISP ho in 
mano il *tuo* eseguibile che dato un imput mi genera una key, qualsiasi 
input gli darò in pasto mi genererà una key corretta indipendentemente 
dall'algoritmo usato quindi a che mi serve conoscere o meno il codice? 
ho già l'eseguibile...

 è doppia, perchè hai risolto solo il 50% del problema.
facciamo così. la vedi questa hash?
b4270e25c9fadba2b79e18055141d882
ecco, l'ho appena calcolata cifrando una frase con l'algoritmo md5. ora 
che t'ho rivelato l'algoritmo secondo te tu avresti il 50% del problema 
già risolto.
a te le conclusioni...

 Il quale è il *risultato* dell'algoritmo.
Si ma nello specifico l'ISP possiede l'eseguibile che lavora 
indipendentemente dalla stringa che gli viene data in pasto per cui io 
gli passo "
ciccio...@cazzoneso.it
" e lui mi da "ZCHJTHWJNJSNSMMSNN" 
che inserito nell'aplicazione funzionerà o no?
Al ché la domanda.. che me frega del tuo algoritmo? che lo conosco o 
meno non fa differenza se possiedo l'eseguibile che genera le chiavi per 
cui a che serve re-inventarsi la ruota ed occultare gelosamente l'algoritmo?

 
giusto. ma tu questo eseguibile lo puoi solo eseguire.
Ed io, proprio per prevenire questo tipo di misfatto, potrei avere messo 
una sicurezza, cio� che dopo un certo numero di giorni, a meno che io 
non intervenga con una modifica al source, il programma si blocchi.
Quindi chi ha il mio eseguibile se lo prende in quel posto. Ha un 
eseguibile che non gli serve.
Mentre invece se il source � a disposizione sul server, allora qualsiasi 
cretino che ha accesso alla sala del server puo' fregarsi (copiarsi) 
tutto il mio sistema, e se ne fotte anche dell'eseguibile, dato che lo 
puo' generare a piacere. Anzi, puo' anche modificare l'algoritmo e 
nessuno poi puo' pi� provare che lo ha fregato *a me*. Puo' farlo 
passare come una invenzione sua.
C'� una differenza tra avere il source e non averlo. Credimi.

 a te le conclusioni...
come dici tu, non farmi lavorare a questora.
A me basta il mio algoritmo di cripting artigianale che basta ed avanza.
Sono felice e nessuno finora è riuscito a 'Knackarlo'.
Non é il caso di scomodare nè Nash nè Ron Rivest né Di Crescenzo nè 
Watanabe nè altri geni della cripogtrafia.

 l'algoritmo?
leggi la mia risposta precedente sulle motivazioni per non rendere 
pubblico il source.

 C'è una differenza tra avere il source e non averlo. Credimi.
Credi a me che non c'è differenza se l'eseguibile che genera le key se 
ne va a spasso su server che non sono sotto il tuo controllo.
L'unico modo sicuro di implementare una funzionalità simile è che al 
momento dell'acquisto del programma venga generato un file licenza in 
chiaro tipo XML contenente i dati del cliente, poi tu firmi digitalmente 
il suddetto e lo invii all'utente, al momento dell'installazione il 
programma richiede il file XML.pm7, verifica la validità della firma 
digitale e carica il contenuto del file visualizzando la licenza ogni 
volta che il programma viene lanciato tipo "Questo programma è concesso 
in licenza a XXY.S.p.a Partita Iva 56789765678 ogni abuso... 
contattare.. ecc.." questo scoraggia molto..
O meglio ancora se hai familiarità con PKCS#11 & co. interfacciandolo ad 
un token USB per cui devi fisicamente avere il token inserito sennò 
l'applicazione non parte ed il problema è risolto alla radice.
Certo sono metodi che non servono per programmini da 25€...


In tal caso l'unico rimedio è mantenere il sorgente all'interno di un 
proprio server (es: web) che non sia presso terzi e in tal modo hai la 
certezza che l'accesso fisico al server sia esclusivo (solo da parte tua) 
oppure autorizzato a un numero ristretto di persone; cosi facendo hai una 
tutela maggiori.
Vedi ad esempio le grosse aziende: microsoft, google, yahoo... non si 
affidano a fornitori di hosting o webfarm esterne ma ne hanno di proprie 
all'interno della azienda stessa..
-- 
Impastato Marcello
www.blueware.it
 


Le chance sono sempre le stesse; un programma per essere eseguito deve 
essere caricato in memoria e quindi avviato. Per essere caricato in memoria 
deve necessariamente essere non-protetto quindi la key a questo punto non 
aiuta più.
Un dump della memoria ti rivela il programma compilato senza la protezione 
della key... e quindi aggiri il problema.
-- 
Impastato Marcello
www.blueware.it
 

 
Ci siamo confusi.  Io chiamo 'key' sia la 'product key' che io do' al 
cliente per attivare il programma (una volta sola), sia la 'running o 
fixed key' che l'algoritmo di cripting usa per lavorare.
Sono due cose diverse. Ma ho capito quello che vuoi dire. Sì, una voltza 
in memoria, se il programma è stato 'aperto' puoi risalire iin teroia 
all'algoritmo.
Ma anche se non è stato aperto. Infatti io 'apro' la demo version.
Che si differenzia dalla versione operazionale solo per il fatto che 
impedisce alcuni save e print. Nientaltro.
Quindi avendo i memoria anche la demo version uno col reverse 
engineering potrebbe scoprire come funziona il  mio programma.
Niente di speciale.
Comunque, in tutte queste belle e interessanti discussioni sul cgi, dove 
siamo finiti a parlare di cripting e di source, non ho ancora capito 
'come' funziona il cgi. Cioè 'cosa' si deve dare al provider, se basta 
dargli l'eseguibile o se (come penso) bisogna dargli il source almeno la 
prima volta, per farlo compilare su *quella* macchina, come lo si 
inquadra in un sistema di web server programming ad esempio basato su 
php, che tipo di contratto va fatto col ISP, etc.
Io queste cose non le ho mai fatte. Se c'è qualcuno qui che le conosce 
bene magari mi puo' dare qualche consiglio.
:-)
Ciao.
John.

 
Eh sì. Purtroppo hai ragione. :-))
Ma qui entriamo in un'altra categoria di costi. Devi ottenere dalle 
poste uno o più indirizzi fissi, devi avere un system engineer che ti fa 
la system maintenance, che è in servizio 24h su 24 e tante altre belle 
cose.... :-)))
Io comincio adesso a immettere un prodotto sul mercato. Puo' andarmi 
buca e vendere un prodotto al mese. (Costo del prodotto : 25 euro).
E allora chi me lo paga il system engineer e l'affitto degli IP fissi 
???  :-))

 Watanabe nè altri geni della cripogtrafia.
se la metti su questo piano la risposta è facile, ti fai delle pippe 
mentali inutili :) un programma web php/perl/qualsivoglia interpretato 
anche se è presente sul server in formato sorgente mica è visibile a 
tutti, per vederlo bisogna "sfondare" il server. e se ti è sufficiente 
confidare sul fatto che non vale la pena provare seriamente a crackare 
il tuo algoritmo allora a maggior ragione non vale la pena di provare a 
sfondare il server, che normalmente è molto più sicuro (*)
(*) a meno che non ci siano cgi eseguibili compilati con degli 
exploit... <grin>

 
Se e quando vorrò brevettare un source (ammesso che sia possibile) andrò 
all'apposito ufficio e mi informerò della procedura.
Ma in questo caso a me basta che il mio source (che non è una cosa 
fantascientifica) sia 'protetto' il più che si puo' almeno fino a 
quando mi sono ritornati i soldi investiti, e qualcosina di più.
Poi posso corre anche il rischio che arrivino al source.
Il fatto è che si deve ragionare in termini di mercato, non di cripting.
Ad esempio :
1) a un tizio è venuta una idea geniale e la trasforma in software da 
vendere.
2) la mette sul mercato, cioé mette il software (eseguibile) sul mercato 
. Chiunque puo' comprarlo.
Certo esiste il rischio che se l'idea è geniale, presto arriverà la 
concorrenza a produrre lo stesso software, migliore del suo. Però 
scrivere un software richiede tempo e costi. Così vendendo il software 
ad un costo minimo, questo rischio viene meno, perchè il gioco non vale 
la candela. Almeno per un end-user.
3) S einvece è una ditta concorrente che si mette i moo, il lasso di 
tempo che va dall'immissione sul mercato del prodotto di tizio, fino al 
tempo di sviluppo (ad esempio un anno e mezzo) di un nuovo prodotto 
concotrrente, è il lasso di tempo utile che tizio ha, per fare dei soldi.
4) Se si protegge il source, questo lasso di tempo utile è 
salvaguatrdato. Se invece il source cade in mano a qualcun altro, e gli 
sposta solo una virgola, questo lasso di tempo si restringe ad uno o due 
giorni. Cioè il tempo di cambiare la virgola nel source e farlo passare 
come proprio. Senza rischiare nemmeno una causa penale.
In questo ultimo caso significa che tizio ha lavorato per niente. Solo 
per hobby.
E credimi, tizio avrebbe un sacco di ragioni per incazzarsi.

 sono 'visibili' a chiunque ???
Da chiunque no. Dal provider si`, visto che quel comando "si trasforma" 
in una email che passa per il mailserver su localhost, e a quel punto 
diventa una email in chiaro.
La vedra` il tuo provider, il suo relay, tutti i relay in mezzo fino al 
server del destinatario, e infine il destinatario.
Bye.

 php, che tipo di contratto va fatto col ISP, etc.
Presupposto che io sono d'accordo con tutti gli altri che stai facendo 
una cosa inutile, e presupposto che trovi il pir... sistemista che ti 
permette di installare codice closed source nel suo server, ti basta 
sapere l'architettura e il S.O. del server, quindi compilare staticamente 
(con tutte le librerie richieste incluse) il tuo codice, e passarlo 
all'ISP, che quindi configurera` il webserver per richiamare il tuo cgi 
in qualche modo (tipicamente 
http://www.example.net/cgi-bin/tuoesegubile
?
parametri)
Ma credo che a te non serva a niente un cgi, ti basta un eseguibile nel 
tuo spazio web che richiami con system() da PHP.
Ma io, fossi in te, penserei di usare (per esempio) gpg, invece di andare 
a inventarmi algoritmi nuovi.
Bye.


L'algoritmo non è il problema. Un algoritmo cretino-cretino che a me 
basta l'ho già implementato. Funziona e a  me basta.
Non penso che l'algoritmo di cripting delle product key sia il problema.
Devo  aver più paura di una ditta concorrente che con costi minori di me 
si mette a fare la stessa cosa. Quello sì.
Però, come spiegavo se io metto a disposizione il source, invece di 
arrivarci tra un anno e mezzo o due, ci arriva la settimana prossima, ed 
io posso andare a vendere pizze.
Ciao.
John.


il fatto è che io non ho dimestichezza di come funzioni esttamente tutto 
l'apparato ISP, tranne vederlo dal di fuori.
Presumo che TUTTI quelli che lavorano nella sede di un ISP possano, se 
lo vogliono, sapere come accedere a un server e 'guardare' il contenuto 
di TUTTI i files.
E' questo quello a cui stavo pensando. Cioè *tutti* quelli che ci 
lavorano sono potenzialmente abili (e abilitati) a 'vedere tutto' (e 
copiare se lo vogliono) quello che c'é sopra.
E se un ISP ha cento dipendenti.....
Tutto qui il nocciolo della questione.

 programma 'compilato'.
Perché così è più sicuro, eh!
Se sei un troll sei bravo, insisto...
-- 
  Daniele Orlandi						つづく

 io posso andare a vendere pizze.
Se lo metti come cgi, chiunque puo` tentare un bruteforce sul tuo 
programmino closed source, e trasformarlo in un keygen che tu stesso gli 
metti a disposizione. Basta trovare i parametri giusti (alias: comprare 
una copia del tuo software, prendere la chiave che tu gli dai, e sparare 
al tuo keygen i propri dati finche` non restituisce la chiave identica a 
quella acquistata).
Come poi ti hanno detto, la security through obscurity non funziona molto 
bene.
Metti il caso che segui la strada che ti ho detto io: binario statico nel 
tuo spazio web, richiamato da PHP.
Oltre ai dipendenti dell'ISP, basta un piccolo errore di configurazione, 
e il tuo binario e` accessibile in lettura a tutti gli altri clienti 
dell'ISP, che se lo possono copiare nel loro spazio web, scaricarlo, 
farne reverse engineer, ecc.
Se non lo fanno gli altri clienti, puo` farlo l'ISP e i suoi dipendenti.
La soluzione definitiva non c'e`, qualsiasi cosa e` bucabile.
Bye.

 
Quando ti riferisci ai troll, ti stai guardando mica allo specchio ?
Perchè tu seil il prototipo 'par excellence' del troll.
Tu comunichi solamente a mezzo flame.....
Cosa che i troll fanno in internet, (per quello il termine è usato solo 
su internet).
Anche perchè se lo facessero in real life incorrerebbero in un sacco di 
guai.


Se il problema č questo, io personalmente non mi preoccuperei dal momento 
che contrattualmente sussiste l'obbligo di riservatezza. Ciň che conta č che 
tu possa in qualche modo certificare in caso di ricorso alla legge che quel 
codice č tuo e non di terzi.
Basta che ti adoperi per trovare una soluzione in tal senso sul piano legale 
e hai risolto il problema. :)
-- 
Impastato Marcello
www.blueware.it
 


No, sostanzialmente il tuo script cgi viene messo in una cartella cgi 
appositamente creata per questi tipi di script e quindi da qui viene 
richiamato.
-- 
Impastato Marcello
www.blueware.it
 


Se parti dal presupposto di non avere successo allora � meglio non partire, 
se invece credi in ci� che fai allora sei pi� rassicurato e non pensi al 
caso peggiore.
-- 
Impastato Marcello
www.blueware.it
 


ed ecco che siamo arrivati alla fine naturale del thread.
Senza insulti, senza flames, con spiegazioni tecniche chiarissime e pacate.
Grazie.
peccato che non tutti qui dentro abbiano lo stesso stile.
Ciao.
john.

 
Anche te ringrazio di tutti i feedback, chiarissimi, e senza flames.
Molte cose mi sono adesso molto più chiare.
Grazie.
:-))
Ciao.

 Uno puo' costruirseli da solo.
Io insisto nel dire che in questo newsgroup c'è troppa diplomazia.
-- 
  Daniele Orlandi						つづく

 
Hai mai provato a scrivere su  il.lavoro.zulu-webmaster?
Là puoi anche insultare tutti quelli che vuoi e trovare gli 
interlocutori adatti, che non sono diplomatici.

 tranquillamente ricrearla anche tu con un investimento di 3-4000 euro;
Oppure semplicemente affidando i propri server ad un data center *serio* 
tipo 
http://www.telecitygroup.it/sicurezza-data-centre.htm
 come fanno 
banche ed aziende tipo bwin ecc..
In quello di Via Savona avevano armadi blindati da un quarto di rack con 
combinazione + chiave di sicurezza tipo cassaforte, in quello nuovo non 
s� ma basta chiedere..

 si è esperti in assembler.
Oggi c'è la fiera delle genialità è? :)
-- 
  Daniele Orlandi						つづく

 Tu comunichi solamente a mezzo flame.....
Questa è una possibilità.
Ce n'è anche un'altra, ovvero che tu ti stia genuinamente meritando tutto 
ciò. Considerala.
Il problema è che per rendersi conto della portata delle minchiate che si 
sparano bisogna avere una certa infarinatura. E infatti non te ne accorgi.
Ma credo che per il tuo bene te lo si debbe far notare:
Sei una fucina di minchiate in campo informatico da far spavento.
-- 
  Daniele Orlandi						つづく

 interlocutori adatti, che non sono diplomatici.
Non ho capito, dovrebbe essere un insulto? Dovrebbe nascondere una sottile 
ironia?
Dimmelo, così vedo di offendermi per compiacerti :)
-- 
  Daniele Orlandi						つづく

 
sarà mica perchè in campo informatico molto probabilmente io ci sono la 
stessa quantità di anni che ci hai passato tu moltiplicati per quattro e 
nella quantità qualche minchiata qua e là passa sempre ?
E ti garantisco che non sono ancora affetto da alzheimer.

running-key sta su un file sul server, usato dal programma.
OK.
Ora il problema qual e': il programma che tu dai al provider (a me) č un
file chiamato "nph-crypt-util" che io metto nella directory cgi-bin e tu
lo fai chiamare dalle tue pagine con le opzioni opportune.
Ma io provider non so cosa faccia questo programma. E' compilato.
Potrebbe:
a) Criptare l'input e mandarlo in output (come dici tu) e *solo* quello.
b) Oppure, quando riceve come testo in input "OBLURASCHI", cercare tutti
   i virtualhost che gli sono accessibili, gzippare e criptare password,
   numeri di carta di credito e quant'altro, e mandare QUELLO in output.
c) Oppure, quando riceve come testo in input 64+1 K di ralla, a causa di
   un buffer overflow di cui il programmatore non s'e' avvisto, occupare
   il 100% della CPU, o mandare in output 3 Gbit/s di zeri, o che so io.
Ecco perche' su una macchina non esclusivamente tua non č il caso che tu
possa far girare roba.
Su un virtual server tutto tuo, no problem, ovviamente.
Leonardo
-- 
The thoughts of others were light and fleeting,
Of lovers' meeting, or luck, or fame.
Mine were of trouble, and mine were steady:
So I was ready when trouble came.

:-)
Aggiungi al preventivo 25 EUR, e considera l'uso di una cripto-chiave USB;
oppure, ove l'architettura del programma lo consenta, forza dentro qualche
verticalizzazione con elevato potere deterrente: per esempio le stampe che
vengono fuori a norma, con il logo del cliente completo di partita IVA ;-)


usano come modalità di sviluppo per il web...
"...ci sarà un perché" :-D




Alzhaimer non c'entra, lo sanno anche gli alberi che un algoritmo di 
crittografia è insicuro se la sola conoscenza dell'algoritmo permette 
di decriptare. Se vuoi criptare la "common knowledge" dice algoritmo a 
chiave pubblica/privata.
Un motivo particolare per cui non usi, sparo a caso, GnuPG, che è 
certamente sicuro e è molto più semplice e "trusted" da deployare ?
  ngw
-- 
Nicholas Wieland (ngw)
Zooppa CTO
911 Western Avenue, Suite 420
Seattle, WA  98104  US


Il problema del cripting non era cos� importante. E' stata una 
deviazione dal thread. Mi era stato chiesto 'per che cosa mi serviva un 
cgi' ed io ho risposto 'cripting'. E da l� � deviata la discussione.
Quello che dal thread mi interessa di pi� � l'aver ottenuto idee pi� 
chiare di cosa fa un cgi, di come � configurata una attivit� ISP.
La key generation la far� 'offline', cio� il programma � nel mio ufficio 
e per ciascun acquisto o io o la segretaria invier� a mano per email la 
product key.
Se arriver� a fare i milioni col mio programma (probabilit� pi� vicina 
alla fantascienza che alla realt�) allora mi metter� un server in casa e 
diventer� l'ISP di me stesso.
Grazie comunque del feedback.

 diventerò l'ISP di me stesso.
Se arriverai a fare le migliaia di euro trovare un crack per i tuoi 
programmi sarà più facile che comprarli legalmente.
-- 
  Daniele Orlandi						つづく

 
nella mia vita mi sono passati davanti software come Macromedia Director 
(che costava 8000 marchi tedeschi), Ventura Publisher (che costava 5000 
marchi tedeschi) e migliaia di altri, che erano stati 'knackati'.
Oggi trovi su eMule Adobe Suite che include Dreamweaver, Adobe 
Photoshop, Flash.
Ti sembra che io ho voglia di rompermi troppo i coglioni per evitare che 
mi 'knackano' il mio ??
Quando non è nemmeno necessario 'knackarlo' ? Basta che a Timbuctù, (ma 
anche a Napoli, senza andare troppo lontano), uno lo compra UNA VOLTA 
per 25 euro e poi ne fa cinquecento copie e dà a tutti il suo username 
ed il codice che ha ricevuto 'regolarmente' da me, che già ci guadagna 
più che quello che magari ci posso guadagnare io.
L'importante è non rendere la vita troppo facile. Per il resto non ci 
puoi fare niente.
E' come non lasciare la chiave dentro la macchina e la porta aperta. 
Allora se fai così, anche un dodicenne puo' fregarti la macchina e sei a 
piedi.
Se invece chiudi la macchina a chiave, rendi la vita più difficile ai 
ladri. Ma un ladro esperto te la frega lo stesso.
Tutto qui. E la stessa cosa è nella 'protezione' del software (se non 
hai i mezzi di Bill Gates).

Salve a tutti
mi permetto di inserire un commento alla discussione.
Abbiamo avuto gli stessi problemi di John, non per le key che non 
intendo discutere , ma per i Cgi sui server che via via ci sono stati 
'bloccati' su tutti i server che avevamo a disposizione ... spesso 
quando il server ha avuto degli aggiornamenti.
Non sono un 'genio dell'informatica' ma ho risolto mettendo i dati 
necessari su un server sql (mysql) del provider tramite il form di 
richiesta.
Poi da un pc in azienda interroghiamo periodicamente il server sql 
estraiamo i dati ed inviamo automaticamente le email processate da un sw 
in locale... (memorizziamo anche l'ip della richiesta)
Forse ï¿œ un poco ingenua come soluzione ma ci ha risolto i problemi... e 
funziona bene da un paio di anni...
Come si suole dire...  i miei 2 cent...
saluti
Andrea

 grazie.
Sto usando da un annetto circa 
misterdomain.eu
. Sono tizi che stanno 
nella repubblica ceca, se non ho capito male.
Tutto funziona discretamente, comparabilmente col prezzo bassissimo.
Dan