Re: [fpc-pascal] Porting code from Windows D2007, missing Windows functions

2016-07-13 Thread Sven Barth
Am 14.07.2016 07:08 schrieb "Bo Berglund" :
>
> I am porting a Delphi2007 utility from Windows to Linux (Raspbian
> Jessie). It uses a unit I have downloaded from the web, which was said
> to support FreePascal too.
>
> But now I am getting a number of missing identifier errors as follows
> Function calls:
> - SetFilePointer
> - GetFileTime
> - FileTimeToLocalFileTime
> - FileTimeToDosDateTime
> - SetEndOfFile
>
> Constants:
> - FILE_CURRENT
> - INVALID_HANDLE_VALUE
>
> It seems like these are defined in Windows and now in FPC they are
> elsewhere.

Those functions and constants don't exist on non-Windows. Try to convert
your code to one of the abstractions Free Pascal (and also Delphi)
provides, e.g. FileOpen() and friends or TFileStream.

> The uses clause of the unit has the following content:
>
> uses
> {$ifdef MSWINDOWS}
>   Windows,
> {$else}
>   LibC, <== Error here, not found
>   Types,
> {$endif}
>   SysUtils;
>
> It could not find LibC and when I asked on the Lazarus list I got a
> reply to try Unix and/or BaseUnix instead. But this does not work so I
> guess these functions are in another FPC unit somewhere.
>
> What should I add to the uses clause in place of LibC to get it to
> compile on Linux?

The LibC unit only exists on i386-linux and only for compatibility for
Kylix. Other than that you should consider that unit as deprecated and
instead use units like Unix, BaseUnix or Linux, depending on what
functionality you need.

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Porting code from Windows D2007, missing Windows functions

2016-07-13 Thread Graeme Geldenhuys
Sorry, ignore my last message. I see your issue is with RPi (Linux) and
not the Windows platform.

Regards,
  Graeme

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Porting code from Windows D2007, missing Windows functions

2016-07-13 Thread Graeme Geldenhuys
On 2016-07-14 06:08, Bo Berglund wrote:
> uses
> {$ifdef MSWINDOWS}
>   Windows,

Try changing that to {$ifdef WINDOWS} instead.

Regards,
  Graeme

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


[fpc-pascal] Porting code from Windows D2007, missing Windows functions

2016-07-13 Thread Bo Berglund
I am porting a Delphi2007 utility from Windows to Linux (Raspbian
Jessie). It uses a unit I have downloaded from the web, which was said
to support FreePascal too.

But now I am getting a number of missing identifier errors as follows
Function calls:
- SetFilePointer
- GetFileTime
- FileTimeToLocalFileTime
- FileTimeToDosDateTime
- SetEndOfFile

Constants:
- FILE_CURRENT
- INVALID_HANDLE_VALUE

It seems like these are defined in Windows and now in FPC they are
elsewhere.

The uses clause of the unit has the following content:

uses
{$ifdef MSWINDOWS}
  Windows,
{$else}
  LibC, <== Error here, not found
  Types,
{$endif}
  SysUtils;

It could not find LibC and when I asked on the Lazarus list I got a
reply to try Unix and/or BaseUnix instead. But this does not work so I
guess these functions are in another FPC unit somewhere.

What should I add to the uses clause in place of LibC to get it to
compile on Linux?

I am using FPC 3.0 and Lazarus 1.6 on a Raspberry Pi3 with Raspbian
Jessie.

-- 
Bo Berglund
Developer in Sweden

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Is there a way to interact with this list via the Web?

2016-07-13 Thread leledumbo
> Is there a way to interact with this list via the Web?

Alternatively (if you prefer forum-like interface):
http://free-pascal-general.1045716.n5.nabble.com/



--
View this message in context: 
http://free-pascal-general.1045716.n5.nabble.com/Is-there-a-way-to-interact-with-this-list-via-the-Web-tp5725707p5725709.html
Sent from the Free Pascal - General mailing list archive at Nabble.com.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Is there a way to interact with this list via the Web?

2016-07-13 Thread Vasudev Ram
Thank you.


On 7/14/16, Jonas Maebe  wrote:
> Vasudev Ram wrote:
>> Sorry, forgot to put the subject line earlier, so re-sending.
>>
>> On 7/14/16, Vasudev Ram  wrote:
>>> Hi list,
>>>
>>> Is there a way to interact with this list via the Web?
>
> http://blog.gmane.org/gmane.comp.compilers.free-pascal.general
>
>
> Jonas
>


-- 
Vasudev Ram - Dancing Bison Enterprises
- Python, C, Linux, databases, open source, ...
- Web site: https://vasudevram.github.io
- Blog: http://jugad2.blogspot.com
- Blog subscribe:
https://feedburner.google.com/fb/a/mailverify?uri=Jugad2-VasudevRamOnSoftwareInnovation=en_US
About: http://jugad2.blogspot.in/p/about-vasudev-ram.html
ActiveState Code recipes:
https://code.activestate.com/recipes/users/4173351
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


[fpc-pascal] Is there a way to interact with this list via the Web?

2016-07-13 Thread Vasudev Ram
Sorry, forgot to put the subject line earlier, so re-sending.

On 7/14/16, Vasudev Ram  wrote:
> Hi list,
>
> Is there a way to interact with this list via the Web?
>
> By interact, I mean, both read and post messages.
>
> I have seen the main page for the list, where one can subscribe, etc.
> and do know that there are archives. But archives are only for
> reading, and not in a convenient format like a NNTP  newsreader or
> email client.
>
> Is there any way (including third-party, such as Gmane or similar
> tools), by which one can both read messages from, and write messages
> to, the list, via the Web ?
>
> Thanks,
> Vasudev Ram - Dancing Bison Enterprises
> - Python, C, Linux, databases, open source, ...
> - Web site: https://vasudevram.github.io
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


[fpc-pascal] (no subject)

2016-07-13 Thread Vasudev Ram
Hi list,

Is there a way to interact with this list via the Web?

By interact, I mean, both read and post messages.

I have seen the main page for the list, where one can subscribe, etc.
and do know that there are archives. But archives are only for
reading, and not in a convenient format like a NNTP  newsreader or
email client.

Is there any way (including third-party, such as Gmane or similar
tools), by which one can both read messages from, and write messages
to, the list, via the Web ?

Thanks,
Vasudev Ram - Dancing Bison Enterprises
- Python, C, Linux, databases, open source, ...
- Web site: https://vasudevram.github.io
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Resource strings, passwords etc.

2016-07-13 Thread Mark Morgan Lloyd

Tony Whyman wrote:
What's interested me is how this thread has almost looped back to a 
recent thread on that steaming heap of brown stuff know as GTK and the 
attitude of the programmers behind it.


It wasn't intentional :-)

They make the point here that GTK is (too) complex and 
difficult to analyse hence setuid (and setgid) is bad on the grounds 
that no one knows how it could be mis-used.


Assuming that this problem still exists in GTK2, it may get in the way 
of what otherwise could be a good way to solve the original problem in 
this thread.


There's certainly still problems setting running something setuid root, 
I can't speak for using a less-privileged user. I think you might be 
able to work around some (but not all) of the issues using capabilities.


The thing that I found most incredible about the attitude of the GTK 
developers was that they used the fact that Linux changes /internal/ 
interfaces as a precedent that they claimed justified their changing 
/external/ APIs (i.e. as available to application programmers).


--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Resource strings, passwords etc.

2016-07-13 Thread Tony Whyman
What's interested me is how this thread has almost looped back to a 
recent thread on that steaming heap of brown stuff know as GTK and the 
attitude of the programmers behind it.


I had a similar problem a few years ago whiich I wanted to solve by 
putting the passwords in an external file and using file permissions to 
hide it from the bad guys. The file could be owned and only readable by 
root, or better some ordinary user. The preferred solution was to make 
it read/write a non-login user and read only to a group but no one else. 
Users had to be members of the group to read it. Better still was to 
make the program setgid to that group, allowing anyone who could run the 
program (and login into the database) to get access to the password 
controlled info without being able to actually read the password themselves.


However, GTK gets in the way of this because some bozo GTK developer 
thinks they should police use of setuid and setgid from GTK and will 
raise an exception if run from a setgid program. Google "gtk setgid" for 
examples. I can't see a security problem from setgid to a normal group - 
to me its a security mechanism, but you try telling that to the GTK team.


Read http://www.gtk.org/setuid.html for an example of some incredibly 
muddled thinking. They make the point here that GTK is (too) complex and 
difficult to analyse hence setuid (and setgid) is bad on the grounds 
that no one knows how it could be mis-used. They then recommend writing 
an setuid backend in such situations, without recognising that all they 
have done is to move a problem rather than solve it. I wanted my program 
to be setgid so that only it could access privileged information. If I 
write a setgid backend program now I have to find a way of 
authenticating my GTK frontend to my backend (Oh perhaps I should 
have an embedded password).


The point is that while it is reasonable for a developer to give 
guidance on what is good practice, actively stopping a user from using 
your code in a way that you do not approve is not just stupid and 
contemptuous of your users, it can actually get in the way of the right 
solution to a problem that you do not know about.


Assuming that this problem still exists in GTK2, it may get in the way 
of what otherwise could be a good way to solve the original problem in 
this thread.


Tony

On 13/07/16 08:31, Mark Morgan Lloyd wrote:

Michael Van Canneyt wrote:

On Tue, 12 Jul 2016, Mark Morgan Lloyd wrote:

Please excuse one of my regular silly questions. Elsewhere, a 
(former) Delphi programmer is uneasy having found that his binaries 
have had embedded SQL queries, passwords and so on visible "in 
clear" for the last 20 years or so.


Can FPC be told to obfuscate ResourceStrings?


No. The default value for resourcestrings is stored as-is in the binary.

To solve this, I store the username/password encrypted in the binary 
as consts, and they are decrypted when needed.


Sometimes it's difficult to avoid having to do that sort of thing, or 
obfuscating them in an external file.




___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Resource strings, passwords etc.

2016-07-13 Thread Mark Morgan Lloyd

Dennis Poon wrote:

On the subject,  can the OP simply use UPX to encrypt the executable 
binary. It won't be secured but no more unsecured than other simple 
solutions.


I'm the nominal OP, but I raised the question in response to what an 
(ex-) Delphi programmer was asking elsewhere about obfuscators etc. for 
.NET which is what he now uses.


He posts: "...particularly database access strings. I realised I had the 
passwords in plain text, so figured this must be a well-trodden path. 
Found a thread about it from 2006, with detailed discussion. Struck me 
as odd that ten years later it isn't automatically solved in Visual Studio."


--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Resource strings, passwords etc.

2016-07-13 Thread Santiago A.
El 12/07/2016 a las 21:39, Graeme Geldenhuys escribió:
> No, but why the hell would you want to hard-code a password inside an
> executable. Encrypt it externally and read it from a .INI file at
> runtime (or prompt for a password). Even something as simple as
> XorString() is better than nothing - compared to storing it inside your
> source code.
>
> Regards,
>   Graeme
Well, if you don't prompt the password, where do you store the password
to decrypt the externally encrypted password? ;-)

Whenever you try to hide something without storing the password in
user's brain you are just ofuscating. A hard coded password is just
another way of ofuscating strings, but with a higher level of ofuscation.

My solution to store passwords was to store de password in a .INI file
(i.e. user doesn't want to type the password, wants the program to
remember it).

The connection password was encrypted with a hard-coded password and
stored in base64 in the in file.

i.e.

implementation

Const _Password='48-49-50'; // hardcoded ofuscated 123, so in resources
it is not plain

function unofuscate(s):string;
begin
  .
end;

procedure LoadData;
begin
  
  IniPassword:=unofuscate(_Password);
 
ConnectionPass:=SimpleDecrypt(Base64Decode(ini.ReadString('connection','pass','')),IniPassword);
  
end;

I always declared the password in the implementation section, (don't
know where I read that that way there is not a recognizable symbol
"_Password"), if I had to use it in several places, I used ($include
pass.inc}

My ofuscate function was a little more complex, and but anyway, any
system that stores passwords without human intervention is inherently
insecure.

Well, it was long time ago.

-- 
Saludos

Santiago A.
s...@ciberpiula.net

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Resource strings, passwords etc.

2016-07-13 Thread Graeme Geldenhuys
On 2016-07-13 09:54, Dennis Poon wrote:
> May I know what OnGuard is?

It was originally TurboPower OnGuard, but then released as open source
software. It allows you to license your software in many different ways.
eg: x amount of days trial, lease your software for a year at a time, x
amount of uses before it expires etc.

Source code:
  https://github.com/graemeg/onguard

FPC Wiki page:
  http://wiki.freepascal.org/OnGuard


Regards,
  Graeme

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Resource strings, passwords etc.

2016-07-13 Thread Dennis Poon



Graeme Geldenhuys wrote:

On 2016-07-13 08:31, Mark Morgan Lloyd wrote:

Sometimes it's difficult to avoid having to do that sort of thing, or
obfuscating them in an external file.

You could use something like DCPCrypt to help the cause. Or you could
follow similar tactics to what OnGuard uses - encode sensitive text in a
data structure. At the very least use a const of bytes instead of clear
text. For example:



May I know what OnGuard is? googling it returns something irrelevant.

On the subject,  can the OP simply use UPX to encrypt the executable 
binary. It won't be secured but no more unsecured than other simple 
solutions.


UPX is at http://portableapps.com/apps/utilities/free_upx_portable

The original sourceforge.net link is dead, I don't know why.

Dennis
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Resource strings, passwords etc.

2016-07-13 Thread Mark Morgan Lloyd

Lukasz Sokol wrote:

On 13/07/16 08:31, Mark Morgan Lloyd wrote:

Michael Van Canneyt wrote:

On Tue, 12 Jul 2016, Mark Morgan Lloyd wrote:


Please excuse one of my regular silly questions. Elsewhere, a (former) Delphi programmer 
is uneasy having found that his binaries have had embedded SQL queries, passwords and so 
on visible "in clear" for the last 20 years or so.

Can FPC be told to obfuscate ResourceStrings?

No. The default value for resourcestrings is stored as-is in the binary.

To solve this, I store the username/password encrypted in the binary as consts, 
and they are decrypted when needed.

Sometimes it's difficult to avoid having to do that sort of thing, or 
obfuscating them in an external file.



Could it help to try doing this after linking the program binary, to build the 
resources and scramble them
using the program binary part checksum (or have it seed a PRNG and/or derive an 
encryption key / key pair from it) ?

Not that I know how ;) and whether such a thing is viable at all - or desirable 
(since an executable would
always have to be distributed with matching resources build). But how would 
that be for an idea ? ;)


I wonder whether this could this be handled by a step related to i18n.

The whole thing's a bit of a minefield, since there are hacking tools 
out there which can scan a binary looking for regions which are more 
random than expected on the basis that these might be things like crypto 
keys.


--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Resource strings, passwords etc.

2016-07-13 Thread Graeme Geldenhuys
On 2016-07-13 08:31, Mark Morgan Lloyd wrote:
> Sometimes it's difficult to avoid having to do that sort of thing, or 
> obfuscating them in an external file.

You could use something like DCPCrypt to help the cause. Or you could
follow similar tactics to what OnGuard uses - encode sensitive text in a
data structure. At the very least use a const of bytes instead of clear
text. For example:

const
  CKey : TKey =
($E5,$8F,$84,$D6,$92,$C9,$A4,$D8,$1A,$FA,$6F,$8D,$AB,$FC,$DF,$B4);


Regards,
  Graeme

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Resource strings, passwords etc.

2016-07-13 Thread Graeme Geldenhuys
On 2016-07-13 08:28, Mark Morgan Lloyd wrote:
> In that case "No, but why the hell would *one* want to hard-code a 
> password [...] storing it inside *one's* source code."

The English language is perplexing (ie: “clear as dishwater”). There are
a 1001 rules and exceptions to the rules. Both our sentences are acceptable.

Regards,
  Graeme

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Resource strings, passwords etc.

2016-07-13 Thread Lukasz Sokol
On 13/07/16 08:31, Mark Morgan Lloyd wrote:
> Michael Van Canneyt wrote:
>> On Tue, 12 Jul 2016, Mark Morgan Lloyd wrote:
>>
>>> Please excuse one of my regular silly questions. Elsewhere, a (former) 
>>> Delphi programmer is uneasy having found that his binaries have had 
>>> embedded SQL queries, passwords and so on visible "in clear" for the last 
>>> 20 years or so.
>>>
>>> Can FPC be told to obfuscate ResourceStrings?
>>
>> No. The default value for resourcestrings is stored as-is in the binary.
>>
>> To solve this, I store the username/password encrypted in the binary as 
>> consts, and they are decrypted when needed.
> 
> Sometimes it's difficult to avoid having to do that sort of thing, or 
> obfuscating them in an external file.
> 

Could it help to try doing this after linking the program binary, to build the 
resources and scramble them
using the program binary part checksum (or have it seed a PRNG and/or derive an 
encryption key / key pair from it) ?

Not that I know how ;) and whether such a thing is viable at all - or desirable 
(since an executable would
always have to be distributed with matching resources build). But how would 
that be for an idea ? ;)

el es

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Resource strings, passwords etc.

2016-07-13 Thread Mark Morgan Lloyd

Michael Van Canneyt wrote:

On Tue, 12 Jul 2016, Mark Morgan Lloyd wrote:

Please excuse one of my regular silly questions. Elsewhere, a (former) 
Delphi programmer is uneasy having found that his binaries have had 
embedded SQL queries, passwords and so on visible "in clear" for the 
last 20 years or so.


Can FPC be told to obfuscate ResourceStrings?


No. The default value for resourcestrings is stored as-is in the binary.

To solve this, I store the username/password encrypted in the binary as 
consts, and they are decrypted when needed.


Sometimes it's difficult to avoid having to do that sort of thing, or 
obfuscating them in an external file.


--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Resource strings, passwords etc.

2016-07-13 Thread Mark Morgan Lloyd

Graeme Geldenhuys wrote:

On 2016-07-12 21:09, Mark Morgan Lloyd wrote:> I didn't say /I/ was the one 
doing it.
I know and I wasn’t implying you. It’s a figure of speech.


In that case "No, but why the hell would *one* want to hard-code a 
password [...] storing it inside *one's* source code." :-)


--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal