IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Un employé du DOGE devenu conseiller au DOJ s'est vanté par le passé d'avoir piraté et distribué des logiciels piratés,
Ce qui accentue les inquiétudes concernant l'intégrité du personnel du DOGE

Le , par Mathis Lucas

46PARTAGES

6  0 
Elon Musk semble s'être entouré de collaborateurs tous aussi controversés au sein du DOGE. Christopher Stanley, ex-employé du DOGE, s'est vanté de son passé de pirate informatique. Des copies archivées de ses anciens sites Web ont révélé qu'il s'est targué d'avoir piraté et distribué des logiciels piratés. Christopher Stanley, ingénieur de 33 ans, est aujourd'hui conseiller principal au bureau du procureur général adjoint des États-Unis. Il n'est pas le premier employé du DOGE d'Elon Musk avec des antécédents douteux. Un récent rapport a révélé qu'un autre employé du DOGE, Edward Coristine, a fourni une assistance technique à un réseau de cybercriminels.

Un ex-employé du DOGE aurait participé à des activités de piratage informatique

Christopher Stanley, ingénieur de 33 ans, semble être un partisan d'Elon Musk. Il a notamment travaillé dans plusieurs de ses entreprises. Christopher Stanley a travaillé à la fois pour le réseau social X (ex-Twitter) d'Elon Musk et sa société aérospatiale SpaceX. Un ancien fonctionnaire du ministère américain de la Justice (DOJ) et l'annuaire du personnel indiquent que l'ingénieur est à présent conseiller principal au bureau du procureur général adjoint.

On ne sait pas grand-chose sur Christopher Stanley. Mais un nouveau rapport de Reuters suggère que Christopher Stanley a peut-être mené des activités répréhensibles par le passé. Le rapport s'appuie un examen des copies archivées par Internet Archive d'anciens sites Web appartenant à Christopher Stanley.


Christopher Stanley a géré une série de sites Web et de forums dès 2006, alors qu'il avait 15 ans, comme le montrent les données d'enregistrement conservées par la société de renseignement Internet DomainTools. Plusieurs de ces sites distribuaient des copies pirates de livres électroniques, de logiciels et de logiciels de triche pour jeux vidéo. D'après le rapport, Christopher Stanley serait également impliqué dans une campagne de violation de données.

Christopher Stanley s'est vanté d'avoir piraté des sites Web sur au moins deux des forums, selon des messages archivés, dont l'un date de l'époque où il avait 19 ans. À l'époque, il avait déclaré avoir mis fin à ses activités de piratage. Cependant, dans une vidéo YouTube qu'il a publiée en 2014 montre son implication dans la violation de données des clients d'un groupe de piratage rival, alors qu'il avait 23 ans. Ses antécédents soulèvent plusieurs questions.

Christopher Stanley a été affecté au ministère de la Justice alors qu'il travaillait pour le DOGE d'Elon Musk. Le milliardaire a déclaré qu'aucune organisation n'a été plus « transparente » que le DOGE, mais il y a eu peu d'informations publiques sur les responsabilités et les antécédents de son personnel.

Le mois dernier, un rapport a révélé qu'un employé du DOGE appelé Edward Coristine a fourni des services informatiques à un acteur de la menace qui s'est vanté de faire du trafic de données volées et de cyberharcèlement d'un agent du FBI. Elon Musk a défendu son employé dans un message publié sur X.

Les antécédents de Christopher Stanley soulèvent des questions sur son intégrité

Les professionnels de la sécurité nationale étaient largement partagés sur le sérieux à accorder au passé de Christopher Stanley. Selon le rapport, six anciens fonctionnaires du département de la Justice estiment que les antécédents de l'ingénieur de 33 ans soulèvent des drapeaux rouges, notant que le ministère traite des informations sensibles, y compris des détails d'enquêtes fédérales et d'autres informations protégées par les règles du secret du grand jury.

« Je serais très inquiet de l'engager et de lui donner accès à ce type de dossiers », a déclaré Jonathan Rusch, qui a passé plus de 25 ans en tant que procureur du ministère de la Justice avant de se lancer dans le monde universitaire. Selon lui, les antécédents de Christopher Stanley sont inquiétants, en particulier pour un employé du ministère de la Justice, parce qu'il avait divulgué des données qu'il avait apparemment acquises « de manière illégale ».

Dan Guido, dont la société de sécurité numérique Trail of Bits a travaillé avec les ministères de la Justice et de la Défense, s'est montré plus indulgent. « Les antécédents de Stanley en matière de piratage informatique ne devraient pas le disqualifier pour travailler au ministère de la Justice », a-t-il déclaré.

Christopher Stanley utilisait différents pseudonymes sur ses sites et forums, notamment eNkrypt et Reneg4d3, qu'il utilise encore sur certains comptes de médias sociaux. Le rapport établit un lien entre les sites Web des forums et les pseudonymes de l'ingénieur en recoupant les données d'enregistrement des sites avec son ancienne adresse électronique et en faisant correspondre les données biographiques de Reneg4d3 avec celles de Christopher Stanley.

Dan Guido a cité la façon dont Christopher Stanley a ciblé d'autres pirates informatiques comme facteurs atténuants. « C'est une façon d'apprendre que j'ai vue chez beaucoup de gens », a-t-il déclaré. Toutefois, les révélations sur Christopher Stanley accentuent les critiques à l'égard du DOGE d'Elon Musk.

Les activités de piratage mises en lumière par les copies archivées des sites Web

Sur certains des premiers sites de Christopher Stanley, il s'est attribué le mérite du piratage. Le site "fkn-pwnd.com", lancé en 2006 alors qu'il était au lycée, se vantait dans les termes suivants « Fucking Up Servers ! », et présentait un croquis grossier d'un pénis, selon une copie du site conservée par Internet Archive. Les archives révèlent qu'il a enregistré le site Web "reneg4d3.com" l'année et il y a présenté un certain nombre de ses initiatives réussies.

Sur reneg4d3.com, Christopher Stanley a décrit comment il a détourné un forum de discussion concurrent. Dans un message de 2008, Christopher Stanley, il a déclaré avoir obtenu « un accès administrateur », décrivant les opérateurs du site concerné comme des « imbéciles ». « Exploitation facile », écrit-il.

À la même époque, un site concurrent de logiciels de triche pour jeux vidéo, "rev0lution-cheats.com", a été détourné et défiguré. L'attaquant a laissé le message suivant : « ce site a été piraté par "RENEG4D3.com" ». D'après une capture d'écran du site conservée par DomainTools, le site "Reneg4d3.com" a été suspendu par son fournisseur d'accès à Internet quelques mois plus tard. Reneg4d3 est l'un des pseudonymes utilisés par Christopher Stanley.

Dans son rapport, la publication a déclaré qu'elle n'a pas été en mesure de corroborer certains aspects de l'activité de piratage de Christopher Stanley, notamment l'identité du site Web que l'ingénieur a revendiqué avoir détourné ou les circonstances de la dégradation du site "rev0lution-cheats".

Par la suite, Christopher Stanley a lancé d'autres sites où lui et d'autres participants discutaient de piratage, de tricherie dans les jeux vidéo ou de piratage. Les copies conservées par Internet Archive montrent qu'il s'agit des sites "error33.net" et "electonic.net" (sic). À l'âge de 19 ans, Christopher Stanley a annoncé publiquement qu'il se distanciait de « toute activité cybernétique malveillante » dans un message archivé de 2010 sur "electonic.net".

Dans son message, Christopher Stanley a écrit : « je ne pirate plus PayPal, je n'accède plus à l'ordinateur d'autrui (sic) et je n'exploite plus les sites Web en ligne comme StickAM ». StickAM est une référence apparente à un service de diffusion en direct de vidéo qui a fermé ses portes en 2013.

Certaines archives supprimées d'Internet Archive après la publication du rapport

Les responsabilités de Christopher Stanley au sein du ministère américain de la Justice n'ont pas pu être déterminées clairement. Le bureau du procureur général adjoint, dirigé par l'ancien avocat privé du président Donald Trump, Todd Blanche, supervise tous les bureaux des procureurs des États-Unis et gère les enquêtes criminelles sur une série d'infractions, y compris le piratage informatique et d'autres activités cybernétiques malveillantes.

Le rapport n...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de TJ1985
Membre chevronné https://www.developpez.com
Le 05/04/2025 à 11:45
En fait, lorsqu'on parle d'application "COBOL", nous n'avons pas forcément la même image. Lorsque je travaillais dans cet environnement, sous VMS, une application COBOL c'était :

- Un compilateur et un langage normé.
- Un gestionnaire de fenêtres (mode caractères). Il y en avait trois chez DEC, mon favori étant DEC Forms, qui fut choisi.
- Un moniteur transactionnel, ACMS.
- Une base de données relationnelle, RdB.
- Un langage de scripts systèmes, DCL.

Ajoutons un dictionnaire centralisé qui marchait plus ou moins, un éditeur puissant (TPU puis LSE), la gestion des sources (MMS / CMS).

Les applications s'exécutaient sur un cluster VAX, puis AXP, etc, suivant l'évolution des technologies. Le cluster assurait la tolérance aux pannes et la répartition de charge.

Aujourd'hui, je ne sais pas si la notion de moniteur transactionnel existe toujours. Dans le cas contraire, ça veut dire qu'il faut développer une couche de colle entre les modules provenant de COBOL, simplement pour implanter la logique métier qui se cachait dans le moniteur.

Bien sûr, je n'ai l'expérience que d'un "gros" environnement. COBOL est un langage suffisamment complet pour avoir permis des développements complexes monolithiques, sans outils externes. Il emporte en fait tout ce qui était nécessaire à une application de gestion de l'époque (File Section, Screen Section, Report Section) et pouvait très bien travailler tout seul, j'en ai eu plusieurs preuves, constatées et commises.

Lorsque mon client a décidé de quitter C2IHB pour DEC, une guerre des chefs a eu lieu : L'ancien tenait pour une conversion des applications, le nouveau affirmait pouvoir tout réécrire en deux ans... Donc, après trente ans les derniers modules convertis ont finalement pu être débranchés !

Un point : 60 millions de lignes de code, pour du COBOL, ce n'est pas énorme. Un programme fait très facilement 1000 lignes pour dire bonjour. Un programme "utile" fait facilement 10'000 lignes. On arrive donc à 6'000 modules, ce qui n'est pas rien mais pas effrayant non plus.

Ceci pour dire que les évaluations données par Musk me semblent aussi fiables que ses prévisions de disponibilité de l'AutoPilot Tesla...

Quant à moi, j'ai lu Bill Gates, je lis Paul Allen, déçu par Lazarus je me mets à l'Assembleur, Na ! ;-D
5  0 
Avatar de Guesset
Expert confirmé https://www.developpez.com
Le 11/04/2025 à 23:04
Bonjour,

La migration du COBOL vers un autre langage sera aussi difficile pour des questions d'âge.
Les vieilles applications accumulent du code mort. Par exemple, une nouvelle règle s'impose, alors on développe un module pour la prendre en charge, mais on garde l'ancienne règle active pour traiter les dossiers en cours. Normalement, au bout d'un certain temps l'ancienne règle devrait être retirée, mais c'est rarement (jamais ?) fait. Et des scories s'accumulent.
Alors, faire une migration permettrait d'avoir, non pas une nouvelle application, mais une vieille application avec des habits neufs.

En outre, je suis toujours fasciné par notre aptitude à croire à la magie. Aujourd'hui cela s'appelle IA. Tous les outils ont leur intérêt et leur limitations.
L'IA a besoin de modèles construits sur la base de (très) nombreux exemples.
Mais des exemples de migrations COBOL vers C++ ou n'importe quoi, il n'y en pratiquement pas (même le simple accès aux sources COBOL des grosses applications est très protégé).
Donc pas de baguette magique. Et cela malgré la simplification outrancière que je fais en réduisant le problème à un portage entres langages alors que ce serait une migration de tout un écosystème.

Je pense que la solution passera par une duplication croisées des données dans une base actuelle. Puis de commencer des développements par modules autour de cette base. D'abord des fonctionnalités existantes pour vérifier la stabilité comportementale puis, peu à peu, sur de nouveaux modules. Avec un peu de chance, quand la réécriture sera complète, le langage cible sera lui aussi obsolète

Salutations
4  0 
Avatar de Prox_13
Membre éprouvé https://www.developpez.com
Le 11/04/2025 à 17:03
Citation Envoyé par Artemus24 Voir le message
Pourquoi d'avant guerre ? Le COBOL a été créé en 1959 et le premier COBOL que j'ai connu date de la version "68". Depuis, il y a eu beaucoup de progrès fait dans ce langage.
Je ne code pas des monuments d'avant-guerre au marteau-burin, il s'agissait là d'un abus de langage, à l'évidence puisque le langage a été créé en 1959.
Après c'est vrai qu'en un demi-siècle d'existence, le langage a pu évoluer, c'est important de le souligner.

Citation Envoyé par Artemus24 Voir le message
Les mainframes comme IBM fonctionnent pour des langages comme COBOL et ASSEMBLEUR IBM 370 et non sur du 'C/C++' dont les compilateurs ne doivent même pas exister sur ces machines. Il y a aussi la performance en terme de temps d'exécution que l'on ne retrouve sur des mini-ordinateurs qui sont trop lents, ni des problèmes de sécurités comme "RACF" sous IBM.
En effet, les quelques programmes C++ dont nous disposons sont exécutés sur des machines Windows et non sous nos VMS, même si j'ai du mal a comprendre où tu voulais en venir.
Et oui, globalement nous avons fait le même constat:
- Les développeurs juniors ne sont pas intéressés par le langage, mis à part pour toucher une paie commode.
- Les règles métiers accumulées depuis 40 ans sont difficilement traduisibles, surtout quand a l'époque la Qualité n'imposait pas une documentation rigoureuse.
- Les performances du code COBOL sont impressionnantes comparées aux alternatives proposées.

Mais je suis curieux de savoir quelle pertinence tu as vu sur ce point d'avoir été créé avant ou après les guerres ? Tu as l'air d'avoir quelque chose a dire sur les langages d'avant guerre et ça m'intéresserait de savoir.
2  0 
Avatar de Artemus24
Expert éminent sénior https://www.developpez.com
Le 11/04/2025 à 18:29
Citation Envoyé par Prox_13
En effet, les quelques programmes C++ dont nous disposons sont exécutés sur des machines Windows et non sous nos VMS, même si j'ai du mal a comprendre où tu voulais en venir.
Remplacer les gros ordinateur IBM VM/CMS JCL TSO ISP qui sont très performants, par des mini ordinateurs en migrant le COBOL vers du 'C/C++', risque d'être problématique du point de vue sécurité mais aussi en performance. C'est selon moi, peu réaliste.

Citation Envoyé par Prox_13
- Les règles métiers accumulées depuis 40 ans sont difficilement traduisibles, surtout quand a l'époque la Qualité n'imposait pas une documentation rigoureuse.
Ce problème existe aussi dans les banques où l'on ne sait plus trop comment fonctionner des pans entiers de codes COBOL car il n'y a pas ou plus de documentations pour expliquer ce que ça fait réellement. Sans compter, le nombre considérable d'intervenant qui ont modifié le code, pas toujours d'une bonne manière. Bonjour pour faire une retroingérierie qui sera extrêment complexe, sans rien apporter de bénéfique au final.

[quote="Prox_13"]-Les performances du code COBOL sont impressionnantes comparées aux alternatives proposées.
Entièrement d'accord. Donc pourquoi changer quelque chose qui fonctionne parfaitement ?

Citation Envoyé par Prox_13
Mais je suis curieux de savoir quelle pertinence tu as vu sur ce point d'avoir été créé avant ou après les guerres ?
J'ai réagit sur le fait que le COBOL n'est pas apparu avant guerre mais en 1959.

Citation Envoyé par Prox_13
Tu as l'air d'avoir quelque chose a dire sur les langages d'avant guerre et ça m'intéresserait de savoir.
J'ai connu la fin des perforatrice et des cartes perforées pour écrire un programme. Le seul point positif est qu'à l'époque, on savait programmer car la place manquait et il fallait jongler dans des techniques qui ont totalement disparu aujourd'hui pour gérer la mémoire. C'est comparable entre la règle à calcule et les approximations que l'on faisaient à l'époque et l'avènement aujourd'hui des calculatrices et des ordinateurs qui nous ont simplifié grandement la tâche. Mais croire que la tâche sera plus simple de remplacer le COBOL est selon moi une erreur.
2  0 
Avatar de Def44
Nouveau Candidat au Club https://www.developpez.com
Le 05/04/2025 à 0:51
Certainement pas car c'est essentiellement un problème non pas de conversion mais de faisabilité.
Il y a des astuces utilisés en COBOL qui nécessitent de repenser le code pour l'utiliser dans un nouveau langage. Il faudrait aussi comprendre ces astuces, ainsi que la façon de programmer dans les années 60. Bon courage à ceux qui vont mettre leur nez dans ce type de code.
Visiblement t'aimes quoter les gens et répondre hors sujet. Je dis que c'est faisable, tu me dis que "c'est pas une question de conversion mais de faisabilité".

Sinon, tu as mis le nez dans les innovations IA des dernières semaines / derniers mois ? la progression est hallucinante, et on utilise des IA pour gérer des IA, de sorte que le problème du contexte (c'est le seul réel problème ici) peut être contourné. Visiblement c'est même pas ce qui t'inquiète.
Si tu crois qu'une IA est incapable de "repenser le code", c'est que, je pense, tu ne t'es vraiment pas intéressé au sujet.

Si ce n'est pas impossible c'est donc faisable, qu'importe la complexité.
1  0 
Avatar de Escapetiger
Expert éminent sénior https://www.developpez.com
Le 15/04/2025 à 15:30
Bonjour,
Citation Envoyé par Guesset Voir le message
En outre, je suis toujours fasciné par notre aptitude à croire à la magie. Aujourd'hui cela s'appelle IA. Tous les outils ont leur intérêt et leur limitations.
L'IA a besoin de modèles construits sur la base de (très) nombreux exemples.
Mais des exemples de migrations COBOL vers C++ ou n'importe quoi, il n'y en pratiquement pas (même le simple accès aux sources COBOL des grosses applications est très protégé).
Donc pas de baguette magique. Et cela malgré la simplification outrancière que je fais en réduisant le problème à un portage entres langages alors que ce serait une migration de tout un écosystème. (.../...)
Merci de rappeler les fondamentaux, de mon point de vue Elon Musk joue à l'apprenti sorcier (en allemand : Der Zauberlehrling) avec cette histoire de migration COBOL avec l'IA, nous verrons bien à l'échelle médiatique planétaire le résultat.

En attendant, respectons notre histoire / culture IT commune, pas de baguette magique :

Pas de balle en argent (Wikipedia)

« Pas de balle en argent » (traduction littérale de « No Silver Bullet », et dont le sens est « pas de baguette magique » ) est une expression introduite en génie logiciel dans les années 1980 par Frederick Brooks lorsqu'il a publié No Silver Bullet — Essence and Accidents of Software Engineering. Brooks désigne ainsi l'ensemble des « techniques miracles » censées permettre magiquement d'augmenter la productivité des programmeurs et de diminuer la quantité de bugs dans les programmes produits, et ainsi de tuer le monstre redouté, le dépassement des délais, lors de la réalisation des projets informatiques.

L'expression est un jeu de mots entre d'une part le fait que dans une présentation, les puces au début de chacune des phrases s'appellent en anglais bullet(s), d'autre part le fait qu'une balle d'argent est, dans les légendes, le seul projectile capable d'abattre un lycanthrope, et a donc le statut d'arme miraculeuse.

Brooks, qui a relaté son expérience dans Le Mythe du mois-homme, a par la suite écrit un article marquant, No Silver Bullet, où il met en doute les « technologies miracles » de son temps. L'expression Silver Bullet est depuis entrée dans le langage du génie logiciel. (.../...)
1  1