Toute l’activité

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

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 👍

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

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

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.

Ce serait utile pour des mecs sur Linux ou Mac…

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 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 ?

J'ai vu ça pour la RAM c'est abusé !

j'utilise un I9 14900k avec 64G RAM, franchement ça marche très bien. Le problème majeur en ce moment est le prix de la RAM qui à plus que quadruplé en moins de 2 ans. C'est clairement ce qui va plomber ton budget. A voir si tu repasse en 32G au lieu de 64 pour ne pas eclater le coût. Bruno

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.

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.

Salut, Avez-vous des conseils à me donner pour l'achat d'une tour PC pour l'utilisation de SIRIL / PIXINSIGHT / PHOTOSHOP ? Budget 1500€ max. Merci d'avance.

pour info, on en est à la v98 depuis la jauge de qualité de nuit, j'ai ajouté un module Eclipse. un module météo et seeing version mobile mieux optimisée un module planétarium et des centaines de microns, fonctionnalité utile Ce serait un peu long à détailler. profitez juste

il n'y a pas que le filtre, ton traitement est parfait pour les parties sombres, très maîtrisé, ce qui est assez rare , un poil moin parfait (mais très bon quand meme, je chipote) sur les parties claires qui manque de contraste a mon goût.

la version avec tous les pixels

merci beaucoup Frédo, ça me touche j'avoue que je suis pas mécontent du résultat. Je pense que le filtre dualband 3nm n'y est pas pour rien !

Ceci étant dit, bravo pour ton image , de mon point de vue c'est la plus réussie que tu nous aies montrée jusqu'alors.

je ne comprends pas pourquoi ça ne marche pas pour toi. je n'ai relevé de dépassement de limite et je les ai de toute façon augmentées. Sinon y'a toujours la possibilité de l'héberger sur post image ou encore sur Astrobin puis de publier ici comme je le fais avec cette image par exemple (simple copier-coller d'url, transformé automatiquement en image par le forum)

Envoie-moi ton image sur ftapissier@gmail.com. je vais regarder cela

j'ai ce message : Vous avez utilisé 156.52 Mo sur votre limite de pièces jointes de 48.83 Mo. ça représente l'ensemble des images postées dans tous les post que j'ai fait !

je ne peux insérer qu'une pièce jointe existante via "insérer un autre média". je ne peux pas gérer les images de ma base média

rééssaye ?

je vais regarder ça....

Bonjour Bruno, comment fait-on pour supprimer des images de sa base ? J'ai atteint le quota maxi apparemment. est-ce que parce que je ne suis plus membre Avex ?