Je suis aux Etats Unis depuis 2 semaines pour des raisons familiales, et je n'ai pas vraiment le temps de bosser sur retina. Je serai a nouveau dispo debut juin, donc ne vous inquiétez pas si ça ne bouge pas trop pour le moment

ok....

bon voyage

bon, rassure moi, tu es revenu maintenant ?

Oui...mais je n'ai pas beaucoup de temps Je me rends compte qu entre le nouveau boulot et la famille il reste peu de place pour le reste. J espère régler mes soucis de télescope (j en suis à la phase de transmission du dossier à un tribunal) pour vous rejoindre les nuits

Envoyé depuis mon GT-I9300 avec Tapatalk

Ne t'inquiètes pas, on est patient !!!

Des nouvelles de Jeff ?

C'était sympa de développer un petit logiciel.

Il m'arrive de l'utiliser encore souvent pour voir mes photos.

Quel logiciel utilisez vous pour voir rapidement vos photos ?

Je déterre un peu le sujet, mais je suis en train de m'y remettre

Par contre je n'ai plus les images fits que j'utilisais pour faire mes tests : est-ce que quelqu'un peut me faire un petit lot d'images ?

tu veux quoi : des fichier brute ou des brutes de registration ?

Un petit pack avec les deux si c'est possible Tu m'avais fait un zip sur dl.free.fr, mais le lien n'existe plus et je n'ai plus les fichiers

http://www.-asso.org/filerun/wl/?id=OZgdjMJQHMm22Bm61KH2lsdTk2EUGTq9

il y des darks, 2 masters offset une des images d'une galaxie

Welcome back, Jeff !

Super ! Merci beaucoup !

Ah quel bonheur de voir que tu es de retour.

Ca me fait vraiment plaisir.

Merci :-)

Je suis en train de tout reprendre depuis zéro (nouvelles version des logiciels Qt, Python, etc...) ; quelques années ont passé depuis et je remets le vieux code au gout du jour.

Je mets tout sur github si tu veux suivre : https://github.com/jromang/retina et https://github.com/jromang/retina/commits/master

Toujours rien d'utile pour le moment, mais voici un petit screenshot :

Bon. Début juin.

Alors voilà, j'avais dit « début juin ». Je n'avais pas précisé l'année. Techniquement je n'ai donc menti à personne, et je considère le sujet clos. 😄

Quatorze ans plus tard, j'ai fini par m'y remettre.

J'ai enfin un logiciel qui permet le de traitement d'images astro, avec l'ambition délirante d'aller taquiner PixInsight. Le principe de base, comme à l'origine : le cœur est en Python, et tout est faisable depuis la console intégrée. L'interface n'a aucun pouvoir propre, c'est juste un client de l'API — et chaque clic affiche le code Python équivalent dans la console, copiable et rejouable. On apprend à scripter en cliquant, ce qui est quand même plus sympa que de lire une doc.

Ce qu'il y a dedans, en vrac :

• 141 process (j'ai arrêté de compter, puis j'ai recompté par curiosité, et j'ai été le premier surpris) : calibration, empilement, DBE-like, déconvolution, réduction de bruit, étirements, masques d'étoiles, PixelMath…

• Un pré-traitement automatisé complet, façon WBPP : tu pointes un dossier de brutes, il en sort des masters et des intégrées, avec cache et reprise après interruption.

• Une interface façon VS Code : docking, palette de commandes, éditeur Monaco, viewport WebGL2, previews, masques, historique et undo par vue.

• Accélération GPU sur les trucs lourds (déconvolution ×35 sur ma carte, si on veut bien croire mes propres mesures).

• Plate-solve hors ligne, annotation, WCS, photométrie, mosaïques.

• Des presets pour les télescopes intelligents (Seestar, Dwarf), écrits avec le même sérieux que le reste, c'est-à-dire sur la base de la documentation et de beaucoup d'optimisme.

• Interface bilingue FR/EN, et un installeur MSI pour Windows.

• Et un assistant IA intégré directement dans le logiciel, mais ça n'est pas super efficace d'après mes tests 😅 (Il faut un abonnement Claude Pro en plus)

Et là, la question légitime : comment un type qui a mis quatorze ans à écrire un visualiseur FITS sort d'un coup 141 process ? L'IA. J'ai fait tout ça avec Claude Code, et honnêtement c'est l'expérience de dev la plus déroutante de ma vie : j'ai l'impression d'avoir une équipe de développeurs à mes ordres. Je décris ce que je veux, je discute l'architecture, je râle sur le résultat, ça repart. Moi je reste le chef de projet, celui qui décide, qui relit et qui dit non — mais le volume de code produit n'a plus rien à voir avec ce qu'un type seul peut taper à la main le soir. Sans ça, ce message n'existerait tout simplement pas, et vous auriez été tranquilles quatorze ans de plus.

Le revers de la médaille est direct : c'est très peu testé.

Enfin si — les tests unitaires passent, ce qui prouve essentiellement qu'on a écrit les tests. Mais Retina n'a jamais vu une vraie nuit d'observation, jamais avalé un dossier de brutes d'un vrai setup, jamais été confronté à un capteur qui a chaud, à un flat foireux ou à un fichier FITS écrit par un logiciel créatif. Tout ce que je peux garantir, c'est que ça marche sur mes données de synthèse et sur les quelques jeux que j'ai trouvés en ligne. Autant dire rien. Du code écrit vite, c'est aussi du code qui n'a jamais rencontré la réalité.

Ce qui m'amène au détail qui va faire plaisir à ceux qui me connaissent : je n'ai toujours pas de setup astrophoto. 😁

Oui. J'écris un logiciel capable d'empiler cent poses de 50 mégapixels par bandes de lignes pour ne pas saturer la RAM, et je n'ai personnellement jamais produit une seule pose. Il y a sûrement un mot pour ça. En attendant, c'est exactement pour cette raison que je repasse ici : j'ai besoin de gens qui ont du vrai matériel et de vraies images pour me dire à quel endroit précis ça casse. 😃

Donc si l'un d'entre vous a un dossier de brutes dont il se moque, une soirée à perdre et un goût prononcé pour les messages d'erreur, je suis preneur !

https://kdrive.infomaniak.com/app/share/256623/57b70582-042b-4f7e-8d60-13290dccd076

C'est de l'opensource, tout va rapidement être mis sur github si vous y trouvez un intérêt ^^

Et sinon, au-delà du logiciel : j'espère sincèrement que tout le monde se porte bien par ici. Ça fait plus de dix ans que je traîne dans le coin, même quand je ne donne pas signe de vie — surtout quand je ne donne pas signe de vie, en fait. Content de vous relire.

Merci pour ce super boulot. Pareil, j'ai adopté Claude pour différents projets, un dashboard pour mon observatoire, un autre pour mes camera de surveillance, et plus récemment pour l'application Crépuscule (qui vient de passer le cap de la V100) ! https://avex-asso.org/ftapissier/crepuscules.html

et bien que mon logiciel soi infiniment plus modeste que le tien, je mesure déjà la quantité de travail à accomplir.

je vais tester dès que possible avec un set de brutes encore incomplet imagé il y a deux semaines, mais que j'ai déjà traité en l'état dans pix, ce qui permettrait d'établir des comparaisons.

et tu as raison : avec Claude, on devient des chef de projet. il faut juste beaucoup de pédagogie pour bien contextualiser et cerner ses demandes.

Il est beau, Crépuscule ! Si tu veux qu'on s'y mette ensemble, n'hésite pas - je mets le code sur github et je partage le repo ; j'ai surtout bossé l'architecture et la base telle que je l'avais en tête, il y a encore du pain sur la planche pour l'ergonomie 😅 Par ailleurs Retina peut aussi fonctionner dans un navigateur : je n'en ai pas encore trouvé l'utilité - peut être le faire tourner à distance sur une machine un peu plus puissante ?

Modifié il y a 5 heures5 h par jeff

Hello,

Tiens un petit audit de code:

MSI Retina-0.0.1.msi (installeur WiX pour le logiciel "Retina", traitement d'images astro, embarquant un runtime Python 3.14 complet). J'ai analysé les tables MSI (sans exécuter aucune custom action), extrait le contenu via msiexec /a (admin install, 21266 fichiers, 755 Mo), puis vérifié les signatures Authenticode, les versions des bibliothèques et fait une revue statique du code Python applicatif.

Signature et intégrité

Le MSI lui-même n'est pas signé numériquement (NotSigned).

Retina.exe et la majorité des DLL natives tierces (numpy, scipy, opencv, h5py, PIL/jxl, rawpy, astap_cli.exe...) ne sont pas signées — c'est courant pour des wheels PyPI packagées ainsi, mais ça élimine toute vérification d'intégrité/provenance côté Windows. Seuls Python, OpenSSL, sqlite3 et les runtimes VC++ portent une signature valide (celle de leurs éditeurs amont).

Aucun certificat de l'éditeur "jromang" n'est présent : rien n'atteste que le package vient bien du dépôt GitHub annoncé (github.com/jromang/retina2).

Composants tiers avec CVE connues

Python embarqué : 3.14.4 — des versions ultérieures (3.14.4-2 puis 3.14.5) corrigent plusieurs CVE 2026 (CVE-2026-1502, 2026-4786, 2026-5713, 2026-6100, notamment liées au debugging distant asyncio). Recommandation : mettre à jour vers 3.14.5+.

OpenSSL embarqué : libssl/libcrypto 3.0.19 — le lot de sécurité du 9 juin 2026 (branche 3.0 → 3.0.21) corrige entre autres CVE-2026-45447 (use-after-free dans PKCS7_verify, sévérité High, RCE potentielle) et plusieurs DoS. Recommandation : mettre à jour vers 3.0.21+.

Ces deux composants ne sont pas des vulnérabilités "dans" Retina lui-même, mais c'est la version embarquée qui compte puisque le MSI fige ces binaires.

Code applicatif (app/retina/) — pas de vulnérabilité critique évidente

Pas de secrets/clés API en dur dans le code de l'application (les seules occurrences trouvées sont des fixtures de tests dans les dépendances tierces vendorisées — astropy, astroquery, dask).

subprocess.run(cmd, shell=True, check=True) dans

starremoval.py

: sert à invoquer un outil externe (StarNet/GraXpert) configuré par l'utilisateur via un template de commande. Risque d'injection de commande si ce template peut provenir d'une source non fiable (ex. import d'un fichier de préréglages partagé) plutôt que d'une saisie locale de l'utilisateur — à vérifier/durcir (éviter shell=True, passer une liste d'arguments).

exec(compile(...)) dans app.py (run_recipe) : exécution de code Python arbitraire — c'est une fonctionnalité de scripting délibérée (comme les "process scripts" de PixInsight). Le risque existe seulement si l'utilisateur exécute une recette provenant d'une source non fiable ; ce n'est pas un défaut d'implémentation.

Le serveur local (

security.py

) est bien conçu : jeton aléatoire (secrets.token_urlsafe), comparaison à temps constant, vérification d'Origin sur WebSocket (protection anti DNS-rebinding), cookie HttpOnly + SameSite=Strict, jeton MCP séparé limité à /mcp. Aucun défaut trouvé ici — bon niveau de sécurité pour un serveur loopback.

Divers

Permissions installées sur INSTALLFOLDER (MsiLockPermissionsEx) : Admins + SYSTEM en accès complet, Users en lecture/exécution seulement — pas de dossier applicatif inscriptible par tout utilisateur (évite le DLL hijacking classique).

LaunchCondition exige Windows build ≥ 10240 — rien d'anormal.

Pas de custom actions dangereuses dans la table CustomAction (juste des SetProperty).

Actions recommandées

Mettre à jour le Python embarqué (≥3.14.5) et OpenSSL (≥3.0.21) avant la prochaine release.

Signer le MSI et les binaires de l'application (Retina.exe, astap_cli.exe) avec un certificat Authenticode pour garantir l'intégrité/provenance.

Vérifier l'origine de la valeur self.command dans starremoval.py — si elle peut être importée depuis un fichier de config externe, éviter shell=True.

Python 3.14.4 (avant mise à jour vers 3.14.4-2 / 3.14.5) :

CVE	CVSS v4.0	Sévérité	Description
CVE-2026-6100	9.1	Critique	Use-after-free dans lzma.LZMADecompressor/bz2.BZ2Decompressor/gzip.GzipFile si l'instance de décompression est réutilisée après un MemoryError. Corrigé dans 3.14.4-2.
CVE-2026-4786	7.0	Élevée	Contournement du correctif de CVE-2026-4519 : injection de commande shell via webbrowser.open() avec %action dans l'URL.
CVE-2026-4224	6.0	Moyenne	Stack overflow dans Expat (parsing XML) via un DTD imbriqué profondément — DoS.
CVE-2026-3644	6.0	Moyenne	Contournement incomplet de la validation des caractères de contrôle dans http.cookies.Morsel (bypass CVE-2026-0672).
CVE-2026-5713	5.3 (CVSS v4)	Moyenne	Stack overflow dans le débogage distant asyncio (3.14+) / profiling.sampling (3.15+) — lecture/écriture mémoire arbitraire dans un process privilégié. Exploitation locale, complexité élevée (ASLR).
CVE-2026-1502	5.7	Moyenne	Injection CR/LF dans les en-têtes de tunnel proxy HTTP côté client.
CVE-2026-2297	Medium (pas de score v4 trouvé)	Moyenne	Contournement des hooks d'audit (sys.audit) lors du chargement de fichiers .pyc legacy — fuite d'information.
CVE-2026-0865	Non trouvé (lié à wsgiref.headers)	—	Injection de nouvelle ligne dans les en-têtes HTTP via wsgiref.headers.Headers.

La plus préoccupante est CVE-2026-6100 (Critique, 9.1) : elle touche directement les modules lzma/bz2/gzip, qui sont embarqués dans le MSI (_lzma.pyd, _bz2.pyd présents dans la liste des fichiers). Si Retina réutilise un objet decompressor Python sur un flux réseau ou fichier non fiable après une erreur mémoire, l'UAF est exploitable.

OpenSSL 3.0.19 (avant mise à jour vers 3.0.21) :

Le lot de sécurité du 9 juin 2026 corrige :

CVE	Sévérité	Description
CVE-2026-45447	High	Use-after-free dans PKCS7_verify() — crash, corruption mémoire, potentiellement RCE.
CVE-2026-34182	Moderate	CMS AuthEnvelopedData accepte des messages forgés — bypass d'intégrité ou récupération de clé.
CVE-2026-35188	Moderate	Double-free lors de la vérification OCSP stapling côté client TLS — DoS ou RCE potentielle.
CVE-2026-42764	Moderate	NULL deref dans le traitement des paquets initiaux QUIC serveur.
CVE-2026-45445	Moderate	IV ignoré sur le chemin EVP_Cipher() pour AES-OCB — perte de confidentialité.
CVE-2026-34180, 34181, 42765-42771, 7383, 9076	Low	Divers DoS/NULL deref/heap over-read, exploitabilité limitée ou préconditions rares.

Pour OpenSSL, seul CVE-2026-45447 (High) mérite une vraie attention — il touche PKCS7_verify(), pas directement le chemin TLS standard utilisé par le serveur MCP local de Retina (qui n'utilise pas PKCS7). Le risque concret dépend de si Retina/ses dépendances Python (_ssl.pyd) appellent des fonctions PKCS7/CMS quelque part — je n'ai pas vu cet usage dans le code applicatif examiné.

Il y a 2 heures, jeff a dit :

Il est beau, Crépuscule ! Si tu veux qu'on s'y mette ensemble, n'hésite pas - je mets le code sur github et je partage le repo ; j'ai surtout bossé l'architecture et la base telle que je l'avais en tête, il y a encore du pain sur la planche pour l'ergonomie 😅 Par ailleurs Retina peut aussi fonctionner dans un navigateur : je n'en ai pas encore trouvé l'utilité - peut être le faire tourner à distance sur une machine un peu plus puissante ?

Ce serait utile pour des mecs sur Linux ou Mac…

ok @Guillaume1000R mais il faut raison garder. On n'est pas dans le cadre d'un déploiement dans une infra d'une boite du cac40

De plus, l'application est en v0.01 , c'est plus un truc d'expérimentation.

Il y a 2 heures, jeff a dit :

Il est beau, Crépuscule ! Si tu veux qu'on s'y mette ensemble, n'hésite pas

je ne t'ai pas remercié pour ce petit retour sympa… Que verrais-tu comme amélioration ?

il y a une heure, frédogoto a dit :

ok @Guillaume1000R mais il faut raison garder. On n'est pas dans le cadre d'un déploiement dans une infra d'une boite du cac40

De plus, l'application est en v0.01 , c'est plus un truc d'expérimentation.

Ah pardon je pensais qu'il fallait tester...

il y a une heure, Guillaume1000R a dit :

Ah pardon je pensais qu'il fallait tester...

Mon métier c'est la cyber sécurité, je n'ai pas vraiment d'excuses 😅 Je développe sous Linux, j'ai un peu fait le package windows à l'arrache... Je vais mettre en place le build automatique sur github, avec le suivi des dépendances pour les vulnérabilités, comme ça le sujet devrait être clos pour le futur 👍

Il y a 2 heures, frédogoto a dit :

je ne t'ai pas remercié pour ce petit retour sympa… Que verrais-tu comme amélioration ?

Peut être une fonctionnalité qui affiche les meilleures nuits à venir dans le mois ?