Cc: bug-followup at freebsd.org
Subject: Re: ports/175369: www/chromium: Chromimum Desktop Integration
doesn't open URLs
Date: Wed, 22 May 2013 22:54:54 -0500
--=_623c650f57299628e36235b0bc5439e1
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8
On 2013-05-22 16:13, Ren?? Ladan wrote:
> The update-desktop-database line is part of ports/Mk/Uses/desktop-file-utils.mk [1]which is called by the Makefile,
> so it must be something else...
Looks like there's more than one way to do be the default. IE: Firefox
registers a lot more handlers and such, where chromium only does two. Had to
remove all the other firefox ones before chromium would be default again
though perhaps I should leave firefox on ftp? since chromium doesn't claim it
and when it wasn't set, the IE in wine was launching for it.
For me, it was to try to get chromium to be the default and stay the
default....instead of epiphany (or after I installed calibre -
calibre-ebook-viewer) Which I would fix by having to remember to edit the
mimeinfo.cache file after an update. With this change, it would remain default
after an update (if I forget to reapply this patch, links cause
calibre-ebook-viewer to start...but reapplying the patch and reinstalling the
port was all I needed to do to get chromium back as default.
Chromium is looking for a file named 'chromium-browser.desktop' to determine
the desktop environment and to be able to create application shortcuts, so
that's still right. Not sure how to have chromium compete with firefox. Not
sure how opera is supposed to work if it wants to be default. (the current
problem of how flash is[n't] working in chromium had me thinking if I should
switch browsers again.... right now its chrome/chromium on all the systems,
except for Solaris. Before chrome it was Firefox....and let's not speak of
what things were like before that.)
Perhaps what's needed is to figure out a consistent way for all the browsers
to get along on which ever is the desired default.
Lawrence
Links:
------
[1] http://desktop-file-utils.mk
--=_623c650f57299628e36235b0bc5439e1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
On 2013-05-22 16:13, René Ladan wrote:
The update-desktop-database line is part of ports/Mk/Uses/=
desktop-file-utils.mkwhich is =
called by the Makefile,
so it must be something else...
Looks like there's more than one way to do be the default. IE: Fir=
efox registers a lot more handlers and such, where chromium only does two=
=2E Had to remove all the other firefox ones before chromium would be=
default again though perhaps I should leave firefox on ftp? since chromium=
doesn't claim it and when it wasn't set, the IE in wine was launching for =
it.
For me, it was to try to get chromium to be the default and stay the def=
ault....instead of epiphany (or after I installed calibre - calibre-ebook-v=
iewer) Which I would fix by having to remember to edit the mimeinfo=
=2Ecache file after an update. With this change, it would remain defa=
ult after an update (if I forget to reapply this patch, links cause calibre=
-ebook-viewer to start...but reapplying the patch and reinstalling the port=
was all I needed to do to get chromium back as default.
Chromium is looking for a file named 'chromium-browser.desktop' to deter=
mine the desktop environment and to be able to create application shortcuts=
, so that's still right. Not sure how to have chromium compete with f=
irefox. Not sure how opera is supposed to work if it wants to be defa=
ult. (the current problem of how flash is[n't] working in chromium ha=
d me thinking if I should switch browsers again.... right now its chr=
ome/chromium on all the systems, except for Solaris. Before chrome it was F=
irefox....and let's not speak of what things were like before that.)
Perhaps what's needed is to figure out a consistent way for all the brow=
sers to get along on which ever is the desired default.
Lawrence
--=_623c650f57299628e36235b0bc5439e1--
From webmaster at mikedelta.fr Fri May 24 18:15:43 2013
From: webmaster at mikedelta.fr (webmaster at mikedelta.fr)
Date: Fri, 24 May 2013 20:15:35 +0200
Subject: Flight simulator software and services
Message-ID: <0b8204e2214563fb677da659e091e0b4@mikedelta.fr>
Mikedelta.fr announces:
Flight simulator compatible software and Pilot services
Info for passengers
As a passenger you see sometimes a screen with basic information like
plane altitude, speed and outside temp, then sudenly, you also see a
map showing the flight position, this piece of software is intended to
run on a second monitor, for your passengers of course. For
individuals or cockpit builders put this piece of sofware into your
FSX cockpit.
OUR LOG SYSTEM
Flight Log Client
The SERIES 2 of FLC was born, now with ability to create and submit
flightplans to our network, you can also save them in "FPL IVAO
compatible format" to share with your IVAO application or load them in
further flight logs. Logging your flight data to a lifetime database.
Live Radar
This is our windows live radar client, it allows you to see what's
happening in our virtual sky in real time, it seems like the web
interface (Live radar link)
but with more accuracy.
Also LIKE us in FACEBOOK at www.facebook.com/mikedeltafsxlogsystem
--
If you do not want to receive any more newsletters,
http://mikedelta.fr/adm/lists/lt.php?id=ZklUCwFVBQ1LBE8DBwMEVQ%3D%3D
Forward a Message to Someone
http://mikedelta.fr/adm/lists/lt.php?id=ZklUCwFVBgRLBE8DBwMEVQ%3D%3D
--
powered by phpList, www.phplist.com --
From webmaster at mikedelta.fr Fri May 24 18:25:22 2013
From: webmaster at mikedelta.fr (webmaster at mikedelta.fr)
Date: Fri, 24 May 2013 20:25:15 +0200
Subject: Flight simulator software and services
Message-ID:
Mikedelta.fr announces:
Flight simulator compatible software and Pilot services
Info for passengers
As a passenger you see sometimes a screen with basic information like
plane altitude, speed and outside temp, then sudenly, you also see a
map showing the flight position, this piece of software is intended to
run on a second monitor, for your passengers of course. For
individuals or cockpit builders put this piece of sofware into your
FSX cockpit.
OUR LOG SYSTEM
Flight Log Client
The SERIES 2 of FLC was born, now with ability to create and submit
flightplans to our network, you can also save them in "FPL IVAO
compatible format" to share with your IVAO application or load them in
further flight logs. Logging your flight data to a lifetime database.
Live Radar
This is our windows live radar client, it allows you to see what's
happening in our virtual sky in real time, it seems like the web
interface (Live radar link)
but with more accuracy.
Also LIKE us in FACEBOOK at www.facebook.com/mikedeltafsxlogsystem
--
If you do not want to receive any more newsletters,
http://mikedelta.fr/adm/lists/lt.php?id=ZklXAgRTBAdLBE8DBwYGUg%3D%3D
Forward a Message to Someone
http://mikedelta.fr/adm/lists/lt.php?id=ZklXAgRTBABLBE8DBwYGUg%3D%3D
--
powered by phpList, www.phplist.com --
From Contact at Love4aviation.com Fri May 24 21:12:16 2013
From: Contact at Love4aviation.com (Love4aviation.com)
Date: Sat, 25 May 2013 08:01:08 +1200
Subject: Supersonic tip-May 2013
Message-ID:
An embedded and charset-unspecified text was scrubbed...
Name: not available
URL:
From info at eu.fab.com Mon May 27 05:37:56 2013
From: info at eu.fab.com (Fab)
Date: Mon, 27 May 2013 01:37:53 -0400 (EDT)
Subject: Invite from stripainaisjenots@inbox.lv to Fab
Message-ID: <20130527053753.51a2f131d2f8807a46000289@sailthru.com>
? ? ? If you are unable to see this message, click here to viewTo ensure delivery to your inbox, please add info at eu.fab.com to your address book.
? ?
Great News!chromium at freebsd.org
Here's your exclusive invite from stripainaisjenots at inbox.lv to join FabFab provides daily design inspirations and sales from the world's leading designers at prices up to 70% off retail.
About Help Contact Us Return Policy Shipping Terms Privacy tw fb ?
If you believe this has been sent to you in error, please click to safely unsubscribe.
From bugmaster at freebsd.org Mon May 27 11:06:22 2013
From: bugmaster at freebsd.org (FreeBSD bugmaster)
Date: Mon, 27 May 2013 11:06:22 GMT
Subject: Current problem reports assigned to chromium@FreeBSD.org
Message-ID: <201305271106.r4RB6M7E015514@freefall.freebsd.org>
Note: to view an individual PR, use:
http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).
The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.
S Tracker Resp. Description
--------------------------------------------------------------------------------
f ports/175369 chromium www/chromium: Chromimum Desktop Integration doesn't op
o ports/165635 chromium www/chromium: 17.0.963.56: proxy isn't read by chrome
f ports/165634 chromium www/chromium : 17.0.963.56 doesn't show physical print
3 problems total.
From dfilter at FreeBSD.ORG Wed May 29 08:50:02 2013
From: dfilter at FreeBSD.ORG (dfilter service)
Date: Wed, 29 May 2013 08:50:01 GMT
Subject: ports/175369: commit references a PR
Message-ID: <201305290850.r4T8o1xT078249@freefall.freebsd.org>
The following reply was made to PR ports/175369; it has been noted by GNATS.
From: dfilter at FreeBSD.ORG (dfilter service)
To: bug-followup at FreeBSD.org
Cc:
Subject: Re: ports/175369: commit references a PR
Date: Wed, 29 May 2013 08:42:01 +0000 (UTC)
Author: rene
Date: Wed May 29 08:41:47 2013
New Revision: 319360
URL: http://svnweb.freebsd.org/changeset/ports/319360
Log:
Manually install the desktop file instead of using DESKTOP_ENTRIES, this
allows to set the MimeTypes.
PR: ports/175369 (still open)
Submitted by: Lawrence Chen (lchen at zen.lhaven.homeip.net)
The BSD Dreamer (beastie at tardisi.com)
Added:
head/www/chromium/files/chromium-browser.desktop.in (contents, props changed)
Modified:
head/www/chromium/Makefile
head/www/chromium/pkg-plist
Modified: head/www/chromium/Makefile
==============================================================================
--- head/www/chromium/Makefile Wed May 29 08:30:12 2013 (r319359)
+++ head/www/chromium/Makefile Wed May 29 08:41:47 2013 (r319360)
@@ -42,7 +42,7 @@ RUN_DEPENDS= ${LOCALBASE}/lib/alsa-lib/l
ONLY_FOR_ARCHS= i386 amd64
USE_XZ= yes
-USES= bison pkgconfig
+USES= bison pkgconfig desktop-file-utils
USE_GMAKE= yes
USE_PERL5_BUILD= yes
USE_PYTHON_BUILD= 2.6+
@@ -50,9 +50,6 @@ USE_XORG= scrnsaverproto x11 xproto xscr
USE_GNOME= glib20 gtk20 dconf libxslt
MAN1= chrome.1
-DESKTOP_ENTRIES="Chromium" "Web browser" "${DATADIR}/product_logo_48.png" \
- "chrome %U" "Network;WebBrowser;GTK;" true
-
ALL_TARGET= chrome
# See build/common.gypi for all the available variables.
@@ -78,6 +75,10 @@ GYP_DEFINES+= use_cups=1 \
prefix_dir=${LOCALBASE} \
python_ver=${PYTHON_VER}
+SUB_FILES= chromium-browser.desktop
+SUB_LIST= COMMENT="${COMMENT}" \
+ DATADIR=${DATADIR}
+
OPTIONS_DEFINE= CODECS GCONF PULSEAUDIO CLANG DEBUG
CODECS_DESC= Compile and enable patented codecs like H.264
@@ -196,6 +197,7 @@ do-install:
.endfor
cd ${WRKSRC}/out/${BUILDTYPE} && \
${COPYTREE_SHARE} "locales resources" ${DATADIR}
+ ${INSTALL_DATA} ${WRKDIR}/chromium-browser.desktop ${DESKTOPDIR}
${LN} -sf ${DATADIR}/chrome ${PREFIX}/bin
post-install:
Added: head/www/chromium/files/chromium-browser.desktop.in
==============================================================================
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ head/www/chromium/files/chromium-browser.desktop.in Wed May 29 08:41:47 2013 (r319360)
@@ -0,0 +1,11 @@
+[Desktop Entry]
+Type=Application
+Version=1.0
+Encoding=UTF-8
+Name=Chromium
+Comment=%%COMMENT%%
+Icon=%%DATADIR%%/product_logo_48.png
+Exec=chrome %U
+Categories=Application;Network;WebBrowser;
+MimeType=text/html;text/xml;application/xhtml+xml;x-scheme-handler/http;/x-scheme-handler/https;x-scheme-handler/ftp;
+StartupNotify=true
Modified: head/www/chromium/pkg-plist
==============================================================================
--- head/www/chromium/pkg-plist Wed May 29 08:30:12 2013 (r319359)
+++ head/www/chromium/pkg-plist Wed May 29 08:41:47 2013 (r319360)
@@ -1,4 +1,5 @@
bin/chrome
+share/applications/chromium-browser.desktop
%%DATADIR%%/chrome
%%DATADIR%%/chrome-wrapper
%%DATADIR%%/chrome.pak
_______________________________________________
svn-ports-all at freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-ports-all
To unsubscribe, send any mail to "svn-ports-all-unsubscribe at freebsd.org"
From rene at freebsd.org Wed May 29 12:37:22 2013
From: rene at freebsd.org (=?ISO-8859-1?Q?Ren=E9_Ladan?=)
Date: Wed, 29 May 2013 14:37:19 +0200
Subject: using API keys in the FreeBSD Chromium port
Message-ID: <51A5F67F.3010706@freebsd.org>
Hi,
the patch at [1] enables the use of FreeBSD API keys which allows things
like Google Sync to work. However [3] states that these keys "are not
for distribution purposes and must not be shared with other users".
There has been some discussion about this on how to deal with this for
source-based at [2], but it seems no consensus has been reached. Is it
permitted to include these keys in the FreeBSD Ports Tree, and if not,
are there any alternatives?
Thanks,
Ren? o behalf of freebsd-chromium
[1]
https://github.com/gliaskos/freebsd-chromium/commit/8701e94cc54126d6907d7665b5181e5d53705d90
[2]
https://groups.google.com/a/chromium.org/forum/?fromgroups#!topic/chromium-dev/Qks4W0xLxqc
[3] http://www.chromium.org/developers/how-tos/api-keys
From lkchen at ksu.edu Wed May 29 20:03:47 2013
From: lkchen at ksu.edu (Lawrence K. Chen, P.Eng.)
Date: Wed, 29 May 2013 16:00:00 -0400 (EDT)
Subject: using API keys in the FreeBSD Chromium port
In-Reply-To: <51A5F67F.3010706@freebsd.org>
Message-ID: <805142494.21026729.1369857600745.JavaMail.root@k-state.edu>
So, is this why sometimes chromium says I need to sign in again, but then leaves me endlessly trying to sign in?
I did see that gentoo has it in their ebuild file, with a note:
# Note: these are for Gentoo use ONLY. For your own distribution,
# please get your own set of keys. Feel free to contact chromium at gentoo.org
# for more info.
I can't think of any way to avoid including the keys (in the clear or partially obscured) in the ports tree....and avoid making it a RESTRICTED port and having some hassle in providing an out-of-band means to control the distribution of the info.
----- Original Message -----
> Hi,
>
> the patch at [1] enables the use of FreeBSD API keys which allows
> things
> like Google Sync to work. However [3] states that these keys "are
> not
> for distribution purposes and must not be shared with other users".
> There has been some discussion about this on how to deal with this
> for
> source-based at [2], but it seems no consensus has been reached. Is
> it
> permitted to include these keys in the FreeBSD Ports Tree, and if
> not,
> are there any alternatives?
>
> Thanks,
> Ren? o behalf of freebsd-chromium
>
> [1]
> https://github.com/gliaskos/freebsd-chromium/commit/8701e94cc54126d6907d7665b5181e5d53705d90
>
> [2]
> https://groups.google.com/a/chromium.org/forum/?fromgroups#!topic/chromium-dev/Qks4W0xLxqc
>
> [3] http://www.chromium.org/developers/how-tos/api-keys
From delphij at delphij.net Thu May 30 06:21:30 2013
From: delphij at delphij.net (Xin Li)
Date: Wed, 29 May 2013 23:21:23 -0700
Subject: using API keys in the FreeBSD Chromium port
In-Reply-To: <51A5F67F.3010706@freebsd.org>
References: <51A5F67F.3010706@freebsd.org>
Message-ID: <51A6EFE3.7030306@delphij.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 5/29/13 5:37 AM, Ren? Ladan wrote:
> Hi,
>
> the patch at [1] enables the use of FreeBSD API keys which allows
> things like Google Sync to work. However [3] states that these
> keys "are not for distribution purposes and must not be shared with
> other users". There has been some discussion about this on how to
> deal with this for source-based at [2], but it seems no consensus
> has been reached. Is it permitted to include these keys in the
> FreeBSD Ports Tree, and if not, are there any alternatives?
What's the purpose of these keys? E.g. are they used to encrypt
sensitive information, or are they used to identify that "this user is
running this client, unchanged"?
I personally don't think it's very practical to protect the key -- it
has to be embedded into the binary some way, encrypted or encoded, or
stored as plain text, and has to be decrypted/decoded to plain text
before use, so anyone who do the due diligent would be able to get it,
binary or source code.
The only way to mitigate the problem, I think, would be to use a new
key every new version and invalidate older ones from time to time, but
that doesn't really solve the problem I guess.
Cheers,
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCAAGBQJRpu/jAAoJEG80Jeu8UPuzRxoH/jm0XlV1KrviaxXBW303YaoF
nqvJouXbt5qbgI7u/j3GSToJ/yUZLS0FT3OhLXEClven0nLj5sdR1Ru6EIjlKCwO
6wh6CbMhDhnn08crzFAD7jotDfcXDwX5yoqKsX1U6IE1it1t8K9Nx3nvVIca1bIS
uMSWXpzNF8BPv9cOAjKm+NHAwsrm5qUOxuyiakNM2E/heRkF+6IG5AQwPd5WUKKS
mUl5a8JnkvOf3T+ufFkkq9ehafHG9ADXkMiqvyW2BMb/e1ka6i8zazf6EX4Js19T
tysv12ebw13vGqOXxSZ/62/gOhZJyc8siyPjybfmQ/nCnBiQmV2shBEE1uPO/mE=
=Hi0t
-----END PGP SIGNATURE-----
From geo.liaskos at gmail.com Thu May 30 18:46:46 2013
From: geo.liaskos at gmail.com (George Liaskos)
Date: Thu, 30 May 2013 18:46:45 +0000
Subject: using API keys in the FreeBSD Chromium port
In-Reply-To: <51A6EFE3.7030306@delphij.net>
References: <51A5F67F.3010706@freebsd.org>
<51A6EFE3.7030306@delphij.net>
Message-ID:
>
> What's the purpose of these keys? E.g. are they used to encrypt
> sensitive information, or are they used to identify that "this user is
> running this client, unchanged"?
>
>From what i understand, the key should be unique per "derivative".
It's used to identify the client, like User Agent one could say but with a
quota on API calls.
In this sense the "Official" Chromium port on FreeBSD should have a unique
key.
https://groups.google.com/a/chromium.org/forum/?fromgroups#!topic/chromium-dev/Qks4W0xLxqc
From delphij at delphij.net Thu May 30 19:22:10 2013
From: delphij at delphij.net (Xin Li)
Date: Thu, 30 May 2013 12:22:09 -0700
Subject: using API keys in the FreeBSD Chromium port
In-Reply-To:
References: <51A5F67F.3010706@freebsd.org> <51A6EFE3.7030306@delphij.net>
Message-ID: <51A7A6E1.3000104@delphij.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 05/30/13 11:46, George Liaskos wrote:
>>
>> What's the purpose of these keys? E.g. are they used to encrypt
>> sensitive information, or are they used to identify that "this
>> user is running this client, unchanged"?
>>
>
> From what i understand, the key should be unique per "derivative".
> It's used to identify the client, like User Agent one could say but
> with a quota on API calls.
>
> In this sense the "Official" Chromium port on FreeBSD should have a
> unique key.
>
> https://groups.google.com/a/chromium.org/forum/?fromgroups#!topic/chromium-dev/Qks4W0xLxqc
Ah,
>
ok so this is for identifying the client. I personally don't
think this would work though.
In order to do this, I think the only way would be:
- Don't ship the port with a key. Instead, require the builder
(currently everyone who runs FreeBSD) to acquire one for themselves.
When the key is not present, don't build the features that requires an
API key.
- On FreeBSD package building cluster (as well as PC-BSD ones),
deploy the "official" key and make binaries there.
I don't see how this would even work as expected, though: the key is
embedded in the binary and thus anyone who can run the binary and have
debugging tools would be able to extract it. This situation is
totally different from normal OAuth scenario, where API key is
deployed on servers and protected from being accessed by average
users, and the API provider can easily block misbehaving client when
the key is "stolen".
Cheers,
- --
Xin LI https://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCgAGBQJRp6bhAAoJEG80Jeu8UPuzQusH/2ZmNiv70gPN3U/mioK+O827
lTvIo1ljPQudNwco+EcXxHinJmKYj36dKxtmU4ByJQmpCazBRRufzc0Zc6dZd2FX
v5cwc6QQH9o0gAFafZS1nPxREoBoBQNmxtyutxjseeEqs+e0zbxix4RQJorZXNgE
I2VyOwiVyxeCaeooa83h/0ll0AkQYn9ny/lDJUoph3rq1nGgX8esIO4XdVORXFPJ
mHeixoI+aRtZ963p4T9ljEnJ4yP+nVqIcpsdL8nHQOdiPuNnNdc79AE4d7RhAaaF
LQ3wdj9tRsA3cgmUGe37jkT3VuGEhIi6jci+W1k2uyiecqy4Qfs2lNdj+MOcOPA=
=OYyE
-----END PGP SIGNATURE-----
From geo.liaskos at gmail.com Thu May 30 19:45:23 2013
From: geo.liaskos at gmail.com (George Liaskos)
Date: Thu, 30 May 2013 19:45:22 +0000
Subject: using API keys in the FreeBSD Chromium port
In-Reply-To: <51A7A6E1.3000104@delphij.net>
References: <51A5F67F.3010706@freebsd.org> <51A6EFE3.7030306@delphij.net>
<51A7A6E1.3000104@delphij.net>
Message-ID:
>
>
> - Don't ship the port with a key. Instead, require the builder
> (currently everyone who runs FreeBSD) to acquire one for themselves.
> When the key is not present, don't build the features that requires an
> API key.
> - On FreeBSD package building cluster (as well as PC-BSD ones),
> deploy the "official" key and make binaries there.
>
> I don't see how this would even work as expected, though: the key is
> embedded in the binary and thus anyone who can run the binary and have
> debugging tools would be able to extract it. This situation is
> totally different from normal OAuth scenario, where API key is
> deployed on servers and protected from being accessed by average
> users, and the API provider can easily block misbehaving client when
> the key is "stolen".
I may be wrong but i don't think that this is feasible, you can not expect
every enduser to generate keys so he can use the browser.
We just need a key that will be "blessed" as official for FreeBSD, just
like Debian [0], Gentoo [1], Arch [2] and others have done.
[0]
http://anonscm.debian.org/gitweb/?p=pkg-chromium/pkg-chromium.git;a=blob;f=debian/rules;hb=HEAD
[1]
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/www-client/chromium/chromium-9999-r1.ebuild?view=markup
[2]
https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/chromium
From phajdan.jr at chromium.org Thu May 30 20:23:51 2013
From: phajdan.jr at chromium.org (=?UTF-8?B?UGF3ZcWCIEhhamRhbiwgSnIu?=)
Date: Thu, 30 May 2013 13:23:30 -0700
Subject: using API keys in the FreeBSD Chromium port
In-Reply-To: <51A7A6E1.3000104@delphij.net>
References: <51A5F67F.3010706@freebsd.org> <51A6EFE3.7030306@delphij.net>
<51A7A6E1.3000104@delphij.net>
Message-ID:
Ren? should now have an official response from an @google.com e-mail.
Please let me know if after that there are still some issues - and consider
https://groups.google.com/a/chromium.org/forum/#!forum/chromium-packagersfor
further questions. :)
Pawe?
On Thu, May 30, 2013 at 12:22 PM, Xin Li wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 05/30/13 11:46, George Liaskos wrote:
> >>
> >> What's the purpose of these keys? E.g. are they used to encrypt
> >> sensitive information, or are they used to identify that "this
> >> user is running this client, unchanged"?
> >>
> >
> > From what i understand, the key should be unique per "derivative".
> > It's used to identify the client, like User Agent one could say but
> > with a quota on API calls.
> >
> > In this sense the "Official" Chromium port on FreeBSD should have a
> > unique key.
> >
> >
> https://groups.google.com/a/chromium.org/forum/?fromgroups#!topic/chromium-dev/Qks4W0xLxqc
>
> Ah,
> >
> ok so this is for identifying the client. I personally don't
> think this would work though.
>
> In order to do this, I think the only way would be:
>
> - Don't ship the port with a key. Instead, require the builder
> (currently everyone who runs FreeBSD) to acquire one for themselves.
> When the key is not present, don't build the features that requires an
> API key.
> - On FreeBSD package building cluster (as well as PC-BSD ones),
> deploy the "official" key and make binaries there.
>
> I don't see how this would even work as expected, though: the key is
> embedded in the binary and thus anyone who can run the binary and have
> debugging tools would be able to extract it. This situation is
> totally different from normal OAuth scenario, where API key is
> deployed on servers and protected from being accessed by average
> users, and the API provider can easily block misbehaving client when
> the key is "stolen".
>
> Cheers,
> - --
> Xin LI https://www.delphij.net/
> FreeBSD - The Power to Serve! Live free or die
> -----BEGIN PGP SIGNATURE-----
>
> iQEcBAEBCgAGBQJRp6bhAAoJEG80Jeu8UPuzQusH/2ZmNiv70gPN3U/mioK+O827
> lTvIo1ljPQudNwco+EcXxHinJmKYj36dKxtmU4ByJQmpCazBRRufzc0Zc6dZd2FX
> v5cwc6QQH9o0gAFafZS1nPxREoBoBQNmxtyutxjseeEqs+e0zbxix4RQJorZXNgE
> I2VyOwiVyxeCaeooa83h/0ll0AkQYn9ny/lDJUoph3rq1nGgX8esIO4XdVORXFPJ
> mHeixoI+aRtZ963p4T9ljEnJ4yP+nVqIcpsdL8nHQOdiPuNnNdc79AE4d7RhAaaF
> LQ3wdj9tRsA3cgmUGe37jkT3VuGEhIi6jci+W1k2uyiecqy4Qfs2lNdj+MOcOPA=
> =OYyE
> -----END PGP SIGNATURE-----
>
From lkchen at ksu.edu Thu May 30 22:28:01 2013
From: lkchen at ksu.edu (Lawrence K. Chen, P.Eng.)
Date: Thu, 30 May 2013 18:28:00 -0400 (EDT)
Subject: using API keys in the FreeBSD Chromium port
In-Reply-To:
Message-ID: <1239531525.21357067.1369952880052.JavaMail.root@k-state.edu>
----- Original Message -----
> >
> >
> > - Don't ship the port with a key. Instead, require the builder
> > (currently everyone who runs FreeBSD) to acquire one for
> > themselves.
> > When the key is not present, don't build the features that requires
> > an
> > API key.
> > - On FreeBSD package building cluster (as well as PC-BSD ones),
> > deploy the "official" key and make binaries there.
> >
> > I don't see how this would even work as expected, though: the key
> > is
> > embedded in the binary and thus anyone who can run the binary and
> > have
> > debugging tools would be able to extract it. This situation is
> > totally different from normal OAuth scenario, where API key is
> > deployed on servers and protected from being accessed by average
> > users, and the API provider can easily block misbehaving client
> > when
> > the key is "stolen".
>
>
> I may be wrong but i don't think that this is feasible, you can not
> expect
> every enduser to generate keys so he can use the browser.
>
> We just need a key that will be "blessed" as official for FreeBSD,
> just
> like Debian [0], Gentoo [1], Arch [2] and others have done.
>
> [0]
> http://anonscm.debian.org/gitweb/?p=pkg-chromium/pkg-chromium.git;a=blob;f=debian/rules;hb=HEAD
> [1]
> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/www-client/chromium/chromium-9999-r1.ebuild?view=markup
> [2]
> https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/chromium
And, presumably
https://github.com/gliaskos/freebsd-chromium/commit/8701e94cc54126d6907d7665b5181e5d53705d90
is the official FreeBSD one.
But the question is whether how Debian/Gentoo/Arch, and now FreeBSD, are distributing the keys in violation of
http://www.chromium.org/developers/how-tos/api-keys
"Note that the keys you have now acquired are not for distribution purposes and must not be shared with other users."
I see geolocation is part api keys..is that why it hasn't been working since 23?
Wonder if everybody who runs FreeBSD could just join the FreeBSD team and see the key?