Quali azioni non dovrei fare affidamento sulla funzionalità pacchettizzata della mia lingua?

Penso che potresti confondere le funzionalità della lingua di base con le funzionalità fornite da estensioni e / o toolkit.

Non conosco alcun algoritmo crittografico che prepari un hash per te, motivo per cui il tuo collega ha fatto il suo commento. Ma quella funzione di crittografia non è un aspetto fondamentale della lingua, fa parte di un'estensione.

In generale, è necessario comprendere gli strumenti che si stanno utilizzando indipendentemente dalla loro appartenenza al linguaggio principale o forniti tramite un toolkit.

Se la lingua dice che farà X, Y e Z su invocazione, allora puoi fidarti della lingua per fare X, Y e Z quando la invochi correttamente. Qualsiasi altro risultato sarebbe un bug nell'implementazione di quella lingua. Ciò non ovvia alla necessità di capire cosa fornisce la funzione.

Come esempio correlato, l'allocazione della memoria in C non inizializza il segmento di memoria su un valore preimpostato / predeterminato. In genere è necessario impostare la memoria su un valore predefinito (come 0x00) prima di utilizzarlo. Posso fidarmi che quando chiedo l'allocazione, la memoria è stata allocata (assumendo che il mio puntatore restituito non sia nullo). Ma l'alloc non garantisce che fornirà memoria inizializzata, quindi ho bisogno di farlo da solo.

Come ha detto superM, dipende davvero dalla lingua, dal compito e dal programmatore. Se la lingua (o la libreria) non viene usata molto spesso o l'attività è molto specifica, allora è meno probabile che i bug vengano trovati e risolti rapidamente rispetto a qualcosa che viene comunemente usato.

Normalmente vorrai fare affidamento sulla lingua o sulla libreria più di ogni altra cosa arrotolata a mano semplicemente perché sono state testate per correttezza, robustezza, sicurezza, scalabilità, ecc. ecc. Questo è particolarmente vero in questi giorni per open- librerie di sorgenti poiché la natura di cose come Github rende molto facile per gli utenti casuali inviare patch per correggere un bug particolare.

Tuttavia ci sono rari casi in cui c'è un problema con una lingua / libreria (meno raro per le lingue che non sono comunemente usate) e in tal caso se conosci puoi fare un lavoro migliore , quindi potrebbe essere una buona idea per girare le tue cose. Tuttavia, quando inizi a farlo, assicurati di poter fare un lavoro migliore del software esistente e di non cadere solo per "Non inventato qui" sindrome.

Quasi mai. Ci sono alcune caratteristiche del linguaggio che sono noti per essere inaffidabili. Tipicamente sono tentativi amatoriali di fornire un qualche tipo di sicurezza. mysql_real_escape_string è un tale tentativo. Non usare questo. Non interpolare mai i valori forniti dall'utente, "sanificati" o meno, in istruzioni SQL. Usa istruzioni preparate.

Analogamente, alcune funzioni di numeri casuali della libreria e implementazioni di hash sono note come scadenti o non più sicure (ad esempio DES-56). In questi casi, utilizzare migliori implementazioni di terze parti. Non tentare di scrivere il tuo codice nel tentativo di fornire sicurezza crittografica. Non provare a scrivere un algoritmo di hashing della password. Non provare a scrivere un algoritmo di crittografia. Se le funzioni della libreria standard sono state screditate, utilizza il codice di terze parti rispettato.