I've built the last C version of elog in git, revision 1ebfd06c using mingw-64 ; the resulting binaries work for me on Windows 2019.
Attached is a zip file with the binaries.
I was not able to create a new installer, these are just the executables

> > I trust Stefan is reading this thread and will do something about it. My vote would
> > be to remove the download link to the windows executables and ask Debian to remove
> > the elog package. I think they have a way for upstream developers (Stefan) to request
> > removal of unmaintained out-of-date insecure versions of their stuff. ROOT
> > was in the same situation years ago, the Debian package for ROOT was very old version,
> > also built incorrectly, and everybody complained to us that our stuff does
> > not work (midas, rootana, etc).
> 
> Yeah, I have to recompile the Windows version. Unfortunately my old Windows PC is gone, I
> switched now completely to MacOSX and Linux. Probably have to borrow something from somewhere.
> If anybody can compile the Windows version with the current source code I would be happy.

it would be good if the current state was listed in https://elog.psi.ch/elogs/Vulnerabilities/ 
It seems there's now updated builds for at least windows, and the debian package still outdated?

Personally, I don't think removing download links and pulling packages should be more than a temporary measure.
Treating people fairly IMHO means they should be able to reach a safe version by the same means that brought and left them exposed.

A clear central source would be best, one that has 

- package autobuilds
- source
- cve list

If I understand correctly, currently only the source is up to date?


(I found py_elog on Github, so it could be an easy option to mirror ELOG there and let some free service handle the autobuilds.
I don't know how well one can flag vulnerabilities there, but likely it's possible, and ideally more people would help there.)


p.s.: My hat is off to the sysadmin who checked carefully, I wanted to introduce ELOG in a windows-centric place and I can't swear I would have checked this (official) download as well.

> I've built the last C version of elog in git, revision 1ebfd06c using mingw-64 ; the resulting binaries work for me on Windows 2019.
> Attached is a zip file with the binaries.
> I was not able to create a new installer, these are just the executables

I tried to just exchange the attached binaries in my installation but this didn't worked.
elogd was not able to start.

Regards,

daniel

> > I've built the last C version of elog in git, revision 1ebfd06c using mingw-64 ; the resulting binaries work for me on Windows 2019.
> > Attached is a zip file with the binaries.
> > I was not able to create a new installer, these are just the executables
> 
> I tried to just exchange the attached binaries in my installation but this didn't worked.
> elogd was not able to start.

hmmm strange - did you get an error message or did the binary simply not start?  I've only tested this on a single Windows machine....

> > > I've built the last C version of elog in git, revision 1ebfd06c using mingw-64 ; the resulting binaries work for me on Windows 2019.
> > > Attached is a zip file with the binaries.
> > > I was not able to create a new installer, these are just the executables
> > 
> > I tried to just exchange the attached binaries in my installation but this didn't worked.
> > elogd was not able to start.
> 
> hmmm strange - did you get an error message or did the binary simply not start?  I've only tested this on a single Windows machine....

Error message is:

Error 1053: The service did not respond to the start or control request in a timely fashion.

I have to admit that I'm doing all this on a Server 2012 machine.

> it would be good if the current state was listed in https://elog.psi.ch/elogs/Vulnerabilities/
> It seems there's now updated builds for at least windows

I checked with Stefan and he plans to address both of those fairly soon.

> debian package still outdated?

We reached to the package maintainer (who is not us), if he cannot help,
we will request package removal through debian official channels. Then we have
to repeat same for the ubuntu package.

> A clear central source would be best ...

this already exists. git clone, make, run.

> p.s.: My hat is off to the sysadmin who checked carefully, I wanted to introduce ELOG in a windows-centric place and I can't swear I 
would have checked this (official) download as well.

I usually check the date of stuff I install and go "hmm..." if it is not super fresh or very fresh.

K.O.

 
> it would be good if the current state was listed in https://elog.psi.ch/elogs/Vulnerabilities/ 
> It seems there's now updated builds for at least windows, and the debian package still outdated?
> 
> Personally, I don't think removing download links and pulling packages should be more than a temporary measure.
> Treating people fairly IMHO means they should be able to reach a safe version by the same means that brought and left them exposed.
> 
> A clear central source would be best, one that has 
> 
> - package autobuilds
> - source
> - cve list
> 
> If I understand correctly, currently only the source is up to date?
> 
> 
> (I found py_elog on Github, so it could be an easy option to mirror ELOG there and let some free service handle the autobuilds.
> I don't know how well one can flag vulnerabilities there, but likely it's possible, and ideally more people would help there.)
> 
> 
> p.s.: My hat is off to the sysadmin who checked carefully, I wanted to introduce ELOG in a windows-centric place and I can't swear I would have checked this (official) download as well.

Very good ideas! Go ahead and implement them! We very much appreciate your contribution.

> > > > I've built the last C version of elog in git, revision 1ebfd06c using mingw-64 ; the resulting binaries work for me on Windows 2019.
> > > > Attached is a zip file with the binaries.
> > > > I was not able to create a new installer, these are just the executables
> > > 
> > > I tried to just exchange the attached binaries in my installation but this didn't worked.
> > > elogd was not able to start.
> > 
> > hmmm strange - did you get an error message or did the binary simply not start?  I've only tested this on a single Windows machine....
> 
> Error message is:
> 
> Error 1053: The service did not respond to the start or control request in a timely fashion.
> 
> I have to admit that I'm doing all this on a Server 2012 machine.


Windows Server 2012 itself is almost EOL but it should still work, I believe.  I did see that the elog314-2.exe file is a Win32 binary whereas my binaries are 64bit. On Windows Server 2019 did not cause any issues.
Can you try the following
- extract the new elogd.exe binary somewhere , e.g. c:\temp\elogd.exe
- then type
  cd \Program Files (x86)\ELOG
  \temp\elogd.exe

- post the output/error code that you see.