Do I need an account to report build of Hacakge packages?
I am just curious about how cabal report works. I recently figured out that there is a report command in cabal and it reports the reports generated by --build-reports option when building a package. Is this because I don't have an account on Hackage yet, or because of some other reasons? And if I make an account, where how I put that information in cabal config file? I've looked into the cabal config file and tried to change this myself before, but it wasn't very self explanatory to me. For instance, I tried to make the build-reports on by default, deleting haskell comment like double dashes "--" and put True flag after the colon, but keep getting parse error from cabal. I looked up the manual but it says that the config file is self explanatory, which isn't to me at all. Are there any documentations on this available anywhere? === error messages when I tried to report the build log === kyagrd@kyagrd:~$ cabal report Sending: POST http://hackage.haskell.org/buildreports HTTP/1.1 Content-Type: text/plain Content-Length: 281 Accept: text/plain Creating new connection to hackage.haskell.org Received: HTTP/1.1 404 Not Found Date: Fri, 21 Nov 2008 23:52:14 GMT Server: Apache/2.2.3 (Debian) Alternates: {"HTTP_NOT_FOUND.html.var" 1 {type text/html} {charset iso-8859-2} {language cs} {length 745}}, {"HTTP_NOT_FOUND.html.var" 1 {type text/html} {charset iso-8859-1} {language de} {length 766}}, {"HTTP_NOT_FOUND.html.var" 1 {type text/html} {charset iso-8859-1} {language en} {length 611}}, {"HTTP_NOT_FOUND.html.var" 1 {type text/html} {charset iso-8859-1} {language es} {length 759}}, {"HTTP_NOT_FOUND.html.var" 1 {type text/html} {charset iso-8859-1} {language fr} {length 771}}, {"HTTP_NOT_FOUND.html.var" 1 {type text/html} {charset iso-8859-1} {language ga} {length 813}}, {"HTTP_NOT_FOUND.html.var" 1 {type text/html} {charset iso-8859-1} {language it} {length 692}}, {"HTTP_NOT_FOUND.html.var" 1 {type text/html} {charset iso-2022-jp} {language ja} {length 749}}, {"HTTP_NOT_FOUND.html.var" 1 {type text/html} {charset euc-kr} {language ko} {length 703}}, {"HTTP_NOT_FOUND.html.var" 1 {type text/html} {charset iso-8859-1} {language nl} {length 688}}, {"HTTP_NOT_FOUND.html.var" 1 {type text/html} {charset iso-8859-2} {language pl} {length 707}}, {"HTTP_NOT_FOUND.html.var" 1 {type text/html} {charset iso-8859-1} {language pt-br} {length 753}}, {"HTTP_NOT_FOUND.html.var" 1 {type text/html} {charset iso-8859-1} {language ro} {length 689}}, {"HTTP_NOT_FOUND.html.var" 1 {type text/html} {charset iso-8859-5} {language sr} {length 716}}, {"HTTP_NOT_FOUND.html.var" 1 {type text/html} {charset iso-8859-1} {language sv} {length 722}}, {"HTTP_NOT_FOUND.html.var" 1 {type text/html} {charset iso-8859-9} {language tr} {length 755}} Vary: accept-language,accept-charset Content-Length: 418 Content-Type: text/html; charset=iso-8859-1 cabal: Unrecognised response from server. kyagrd@kyagrd:~$ cabal --version cabal-install version 0.6.0 using version 1.6.0.1 of the Cabal library
On Fri, 2008-11-21 at 16:12 -0800, Ahn, Ki Yung wrote:
I am just curious about how cabal report works.
I recently figured out that there is a report command in cabal and it reports the reports generated by --build-reports option when building a package.
Is this because I don't have an account on Hackage yet, or because of some other reasons?
It's a feature that exists in the client that has no corresponding implementation on the server-side yet. There is a new hackage-server in development that can accept build reports uploaded by "cabal report".
And if I make an account, where how I put that information in cabal config file?
You only need an account for uploading packages. If you do not want to have to enter your user name or password interactively when you run "cabal upload" then you can put them in the config file: username: password: You can use one field without the other field and "cabal upload" will prompt for the one you did not supply. So you don't need to save your password in the config file.
I've looked into the cabal config file and tried to change this myself before, but it wasn't very self explanatory to me. For instance, I tried to make the build-reports on by default, deleting haskell comment like double dashes "--" and put True flag after the colon, but keep getting parse error from cabal. I looked up the manual but it says that the config file is self explanatory, which isn't to me at all. Are there any documentations on this available anywhere?
There is some problems in the config file parsing code it seems. The config file parsing code is derived automatically from the command line parsing code but imperfectly at the moment. For example --build-reports is a boolean value flag but with no argument and these do not seem to be converted correctly into config file fields.
=== error messages when I tried to report the build log ===
kyagrd@kyagrd:~$ cabal report
Yes. The current hackage server does not support uploading build reports. Duncan
You only need an account for uploading packages. If you do not want to have to enter your user name or password interactively when you run "cabal upload" then you can put them in the config file:
username: password:
That sounds like a very bad idea, and should not be encouraged! Any compromised uploader machine with stored passwords can be used to upload compromising code, which will propagate to all downloaders. One bad-apple package installed unwittingly on one uploader machine with stored passwords could compromise all of Haskell land. Claus
On Sat, 2008-11-22 at 15:11 +0000, Claus Reinke wrote:
You only need an account for uploading packages. If you do not want to have to enter your user name or password interactively when you run "cabal upload" then you can put them in the config file:
username: password:
That sounds like a very bad idea, and should not be encouraged! Any compromised uploader machine with stored passwords can be used to upload compromising code, which will propagate to all downloaders. One bad-apple package installed unwittingly on one uploader machine with stored passwords could compromise all of Haskell land.
We've got bigger security issues than this. I'd welcome someone to spend some time implementing some of the obvious and sensible ideas we've discussed to improve the situation. Duncan
On Sat, Nov 22, 2008 at 03:11:34PM -0000, Claus Reinke wrote:
You only need an account for uploading packages. If you do not want to have to enter your user name or password interactively when you run "cabal upload" then you can put them in the config file:
username: password:
That sounds like a very bad idea, and should not be encouraged!
Agreed. However...
Any compromised uploader machine with stored passwords can be used to upload compromising code, which will propagate to all downloaders.
It doesn't really matter whether a compromised machine stores a password or not. If you upload anything using a compromised machine, the attacker has the opportunity to learn your password. Also, Hackage doesn't use SSL/TLS, so compromising a machine isn't necessary for learning Hackage passwords. -- Antti-Juhani Kaijanaho, Jyväskylä, Finland http://antti-juhani.kaijanaho.fi/newblog/ http://www.flickr.com/photos/antti-juhani/
Any compromised uploader machine with stored passwords can be used to upload compromising code, which will propagate to all downloaders.
It doesn't really matter whether a compromised machine stores a password or not. If you upload anything using a compromised machine, the attacker has the opportunity to learn your password.
True. But storing the password means that the owner doesn't need to initiate an upload, nor does the attacker need to capture keypresses, listen on connections, identify uploads/logins/passwords in the captured date, or do anything at all non-trivial, platform-specific or persistent (propagation could ignore the owner's machine).
Also, Hackage doesn't use SSL/TLS, so compromising a machine isn't necessary for learning Hackage passwords.
As Duncan says, an overall security review would be good, the sooner, the better. But that shouldn't prevent incremental improvements whereever they are found. One just needs to keep in mind that they make attacks harder/less likely, not impossible. Encouraging all users to keep an eye on the obvious holes may also make it more likely that the less obvious holes are noticed and addressed. Claus
participants (4)
-
Ahn, Ki Yung -
Antti-Juhani Kaijanaho -
Claus Reinke -
Duncan Coutts