Forumregler
Det er kun medlemmer af gruppen Bestyrelse, og redaktører og administratorer, som kan lave nye indlæg i dette forum. Når først et indlæg er lavet, så kan alle svarer på det.
Omkring en mail-liste er jeg løbet ind i nogle problemer. Jeg tror stadig at en nyhedsliste der sender nyheder og andet (et godt spørgsmål + svar fra forummet, noget fra de sociale medier, alm. nyheder om fx den nye dataforordning) ud en gang om måneden er en god idé, for det vil skabe en form for tilhørsforhold og forhindre interesserede i at glemme forummet og Ubuntu.
Da jeg forslog det konstaterede jeg at der er adskillige open source projekter som laver software til at sende nyhedsmails ud. Det skal fx kunne afmelde afsendere som nægter at modtage emails, for hvis 1 bruger hos Google anmelder nyhedsbrevet som spam, vil Google nægte at modtage til den ene bruger. Fortsætter man alligevel med at forsøge at sende til den bruger, risikerer man at Google slet ikke vil modtage ens e-mails - også for interesserede brugere.
Flere af dem understøtter ikke den funktion og resten gemmer ens kode i klar-tekst. Hvis et open source projekt anno 2017-2018 stadig gemmer koder i klar-tekst, så er der sikkert også andre ting de gør som de ikke burde. Så jeg kan med andre ord ikke finde eksisterende software der er af ordentlig kvalitet. Og jeg syntes ikke at vi skal bruge en online tjeneste, for lige meget om man betaler eller ej, så laver de alle sammen omfattende dataindsamling.
Såeh...
Det efterlader vist kun Mailman. På den anden side kan Mailman også bruges til at videresende de e-mails foreningen modtager automatisk, for ikke at nævne friheden til at oprette de maillister vi måtte have lyst til, så vi ville kunne bruge Mailman til flere ting.
En nyhedsliste med Mailman er bare en en-vejsliste, hvor det kun er nogle få godkendte brugere der kan sende ud, imens resten kun kan modtage. Mailman i sig selv understøtter ikke HTML-baseret e-mails, men jeg fandt et skabelon-system som burde virke fint. Alt i alt lidt omstændigt, men når Mailman først er sat op er det både stabilt og brugervenligt.
At koden ikke er krypteret er vel mest et problem hvis man ikke stoler på dem der generelt får adgang til systemet? Skal det krypteres tænker jeg det er hele installationen det bør gøres ved. Systemet ville jo også skulle have nøglen til at dekryptere koden hvis den skulle kunne bruge det og hvis nøglen ligger sammen med den krypterede data har jeg sværet ved at se den store fordel. De fleste andre koder har vi også liggende i klar tekst eller som klar tekst i databasen.
Jeg er ikke helt sikker på at jeg forstår. De open source nyhedsprogrammer jeg fandt er lavet som hjemmesider i PHP, og for at kunne administrere nyhedsbrevene har man en bruger til hjemmesiden. Det er den brugers kode som ikke er krypteret.
Men ja, programmet kunne bare installeres som et subdomæne, og så blive beskyttet af Apache. På den måde kan koden være 13245 uden nogen problemer.
Faktisk har jeg lavet ~100 linier PHP som kan samle folks e-mail-adresser sammen og gemme dem i Postgres. Så der mangler bare lige den del hvor man kan oprette og sende nyhedsbrevene
function encryptPass($pass) { if (empty($pass)) { return ''; }
if (function_exists('hash')) { if (!in_array(HASH_ALGO, hash_algos(), true)) { //# fallback, not that secure, but better than none at all $algo = 'md5'; } else { $algo = HASH_ALGO; }
Og når udviklerne af phpList ikke kan hitte ud af at passe på folks koder, så er der sikkert også andre problemer med koden. I manualen skriver de fx ikke hvilken database eller PHP versioner der er understøttet.
Sha256 er en hashing algoritme, den kan rigtig nok ikke bruge til at kryptere med, blot til at validere data. Forskellen er at med en hash har man ikke adgangskoden, blot en værdi der kan bruges til at validere at man indgiver den samme kode som oprindeligt. Der er mange der blander de to termer sammen, men det syndes jeg dog ikke er nok til at dømme systemet for usikkert.
Det er faktisk mere sikkert at opbevare en hash end at kryptere og opbevare den egentlige data. Prøv at forestille dig hvad der ville ske hvis systemer generelt krypterede og gemte alle adgangskoder frem for at brugen en hash. De ville skulle have en dekrypterings nøgle som kunne bruges til at dekryptere den gemte data så de kunne sammenligne den med den indgivne adgangskode. Der med ville en hacker der fik adgang til systemet kunne dekryptere samtlige adgangskoder i et huk. Når kun et hash er gemt vil hackeren skulle gætte hver enkelt adgangskode, og man har selv mulighed for at bruge en kode der gør dette svært (hackere bryder ofte kun en %-del af de koder de får adgang til).
Vi kan også konkludere at funktionen du citere ikke bruges til at opbevare en eksisterende adgangskode (eks til vores database) som bruges bagved af systemet, men nok er til at oprette en bruger i selve phpList. Det er også her det hjælper at have en unik adgangskode for hvert system man anvender, så hvis uheldet er ude er det kun koden til det system (som allerede er blevet hacket) at andre kan have fået koden til.
Jeg skal prøve om jeg kan huske at gå på IRC den dag.
Jeg skal lige klippe mit IRC kodeord ud fra min backup, da jeg ikke lige gad at konfigurere IRC den dag jeg havde installeret 16.04 på min stationære.
/Lars
Jeg er Software ingeniør (Diplomingeniør) i Informationsteknologi og indlejede systemer, hvor indlejrede systemer er computer (microcontroller) + elektronik i for eksempel et TV, en router, en vaskemaskine og den slags
