5 ms·

Great idea and use case for IPFS. I'm not sure I want to run php just to host images though. I always have this 'oh... It's in PHP...' moment with things like t

by mrmondo 11y ago

Great idea and use case for IPFS. I'm not sure I want to run php just to host images though. I always have this 'oh... It's in PHP...' moment with things like this and I generally end up not wanting to play with or host them, either because I don't find php attractive as a language or because of the various security issues around hosting php applications.

Gigablah 11y ago
It's worse than that, his PHP scripts make cURL calls to a local nodejs server which then exec() the ipfs commmands.
- toomuchtodo 11y ago
  Ipfs exposes a JSON API locally. Not sure why the author didn't just use a JavaScript front end making calls to the local API. https://ipfs.io/docs/api/ https://ipfs.io/docs/api/ EDIT: I'd encourage the HN community to look past the technical merits of the code, and focus on the idea presented (and even perhaps fork and contribute back an improved version).
  - eis 11y ago
    Hm what prevents some malicious website from pinning unwanted content on a visitors machine?
    - Natanael_L 11y ago
      The visitor needs to chose to run IPFS and cache it
      - eis 11y ago
        He just needs to happen to have IPFS running. Any website can make a request to localhost via Javascript or even without. Scenario: Attacker sends you harmless looking link to a page that contains some invisible JS that sends a request to localhost and pins kiddypon on your IPFS node. Attacker then sends the police to you.
        ossreality 11y ago
        um, cross origin blocking has been a thing for... like a really really long time now.
        mappum 11y ago
        The IPFS API isn't exposed like that, there is actually a whitelist for hashes that can access the API (the IPFS webui is in the whitelist by default), and hashes that are blocked will get a 403.
  - mrmondo 11y ago
    As you suggest, looking past the code quality / implementation choices I believe the idea if solid and it is a creative use of IPFS to attempt to 'solve' a real world problem, I'm excited to see more projects like this.
- mweibel 11y ago
  yep, and doesn't use prepared statements for DB queries..
  - PlzSnow 11y ago
    There's nothing wrong nor insecure about choosing not to use prepared statements. There does seem to be a very conservative/cargo cult streak amongst some tech people that there are only pure ways to do things. For example there is nothing wrong with building a SQL statement as a string and passing it to a database. If it's programmed correctly then it is exactly as secure as a prepared statement.
    - kevan 11y ago
      > If it's programmed correctly then it is exactly as secure as a prepared statement. It's really easy to program them incorrectly, and as a result the approach is less secure than just using prepared statements.
    - mweibel 11y ago
      of course it was a bit of a generalization. However I don't think it's harder to use prepared statements and I do think you should always use it, even if you're absolutely sure that the data you get in isn't an injection. Not using it rings an alarm bell IMO.
    - __david__ 11y ago
      > If it's programmed correctly then it is exactly as secure as a prepared statement. That's a very big "if" right there. The same could be said for nearly every security flaw ever—if it were programmed correctly, it wouldn't be a security flaw. The reason people harp on prepared statements is not because you can't be secure without them, but that it's much easier to be secure with them. One you have to think about all the time (do I need to escape, do I not need to escape), while the other is almost completely secure against SQL injections by default. Same thing with using system() vs execve()[1]. One is a minefield of quoting issues, the other has none. [1] Or multi-arg system(), like in Perl or Ruby.
    - 11y ago
- mrmondo 11y ago
  Wow ok, that's even worse than I anticipated.
reustle 11y ago
Would be nice if the repo came with a dockerfile where you could just "docker run -d" on your server and it would do everything automagically. You'd just need to point nginx at it.
- LaFolle 11y ago
  Docker image for IPFS implemented in Golang is present here: https://hub.docker.com/r/jbenet/go-ipfs/ https://hub.docker.com/r/jbenet/go-ipfs/. Haven't tried though.
- mrmondo 11y ago
  Yes it would be, but that doesn't solve the security issues with PHP or Node.
PlzSnow 11y ago
It's 2015, there are not "security issues around hosting php applications" otherwise half the internet wouldn't work. There does seem to be a "cargo cult" attitude to PHP amongst a large part of the tech sector.
- 1ris 11y ago
  IMHO PHP get's treated fairly. It's possible to write secure and well designed programs in it, it's just very hard. And in fact I'd argue that half of the internet does not work. We life in a world where zerodays are ubiquities. I just think that languages like c and especially c++ do not get their fair amount of laughter, that php gets.
- rsync 11y ago
  "It's 2015, there are not "security issues around hosting php applications" otherwise half the internet wouldn't work." PHP adds complexity and therefore adds fragility and insecurity. Running PHP ipso facto adds insecurity to an environment. There are many ways to do web programming that do not add server daemons or listening ports, or long running processes, or additional logins, passwords and management interfaces.

by mrmondo 11y ago

Gigablah 11y ago

It's worse than that, his PHP scripts make cURL calls to a local nodejs server which then exec() the ipfs commmands.

toomuchtodo 11y ago
Ipfs exposes a JSON API locally. Not sure why the author didn't just use a JavaScript front end making calls to the local API. https://ipfs.io/docs/api/ https://ipfs.io/docs/api/ EDIT: I'd encourage the HN community to look past the technical merits of the code, and focus on the idea presented (and even perhaps fork and contribute back an improved version).
- eis 11y ago
  Hm what prevents some malicious website from pinning unwanted content on a visitors machine?
  - Natanael_L 11y ago
    The visitor needs to chose to run IPFS and cache it
    - eis 11y ago
      He just needs to happen to have IPFS running. Any website can make a request to localhost via Javascript or even without. Scenario: Attacker sends you harmless looking link to a page that contains some invisible JS that sends a request to localhost and pins kiddypon on your IPFS node. Attacker then sends the police to you.
      - ossreality 11y ago
        um, cross origin blocking has been a thing for... like a really really long time now.
      - mappum 11y ago
        The IPFS API isn't exposed like that, there is actually a whitelist for hashes that can access the API (the IPFS webui is in the whitelist by default), and hashes that are blocked will get a 403.
- mrmondo 11y ago
  As you suggest, looking past the code quality / implementation choices I believe the idea if solid and it is a creative use of IPFS to attempt to 'solve' a real world problem, I'm excited to see more projects like this.
mweibel 11y ago
yep, and doesn't use prepared statements for DB queries..
- PlzSnow 11y ago
  There's nothing wrong nor insecure about choosing not to use prepared statements. There does seem to be a very conservative/cargo cult streak amongst some tech people that there are only pure ways to do things. For example there is nothing wrong with building a SQL statement as a string and passing it to a database. If it's programmed correctly then it is exactly as secure as a prepared statement.
  - kevan 11y ago
    > If it's programmed correctly then it is exactly as secure as a prepared statement. It's really easy to program them incorrectly, and as a result the approach is less secure than just using prepared statements.
  - mweibel 11y ago
    of course it was a bit of a generalization. However I don't think it's harder to use prepared statements and I do think you should always use it, even if you're absolutely sure that the data you get in isn't an injection. Not using it rings an alarm bell IMO.
  - __david__ 11y ago
    > If it's programmed correctly then it is exactly as secure as a prepared statement. That's a very big "if" right there. The same could be said for nearly every security flaw ever—if it were programmed correctly, it wouldn't be a security flaw. The reason people harp on prepared statements is not because you can't be secure without them, but that it's much easier to be secure with them. One you have to think about all the time (do I need to escape, do I not need to escape), while the other is almost completely secure against SQL injections by default. Same thing with using system() vs execve()[1]. One is a minefield of quoting issues, the other has none. [1] Or multi-arg system(), like in Perl or Ruby.
  - 11y ago
mrmondo 11y ago
Wow ok, that's even worse than I anticipated.

reustle 11y ago

Would be nice if the repo came with a dockerfile where you could just "docker run -d" on your server and it would do everything automagically. You'd just need to point nginx at it.

LaFolle 11y ago
Docker image for IPFS implemented in Golang is present here: https://hub.docker.com/r/jbenet/go-ipfs/ https://hub.docker.com/r/jbenet/go-ipfs/. Haven't tried though.
mrmondo 11y ago
Yes it would be, but that doesn't solve the security issues with PHP or Node.

PlzSnow 11y ago

It's 2015, there are not "security issues around hosting php applications" otherwise half the internet wouldn't work. There does seem to be a "cargo cult" attitude to PHP amongst a large part of the tech sector.

1ris 11y ago
IMHO PHP get's treated fairly. It's possible to write secure and well designed programs in it, it's just very hard. And in fact I'd argue that half of the internet does not work. We life in a world where zerodays are ubiquities. I just think that languages like c and especially c++ do not get their fair amount of laughter, that php gets.
rsync 11y ago
"It's 2015, there are not "security issues around hosting php applications" otherwise half the internet wouldn't work." PHP adds complexity and therefore adds fragility and insecurity. Running PHP ipso facto adds insecurity to an environment. There are many ways to do web programming that do not add server daemons or listening ports, or long running processes, or additional logins, passwords and management interfaces.